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The  objective  of  this  study  vas  to  provide  software  developers  with 
guidance  in  the  selection  of  Runtime  Environments  (RTEs)  to  ensure  that  all 
timing  and  storage  requirements  of  real-time  embedded  systems  can  be  met. 
Because  there  is  no  ''universal  best'  runtime  environment  (RTE) ,  the 
selection  of  an  RTE  is  domain  specific.  This  study  developed  a  step-by-step 
process  that  a  developer  can  use  to  evaluate  RTEs.  This  process  was  applied 
to  one  class  of  systems,  Communication  and  Electronic  Intelligence 
(COMINT/ELINT)  systems.' 

- - 

A  process  was  developed  to  determine  which  Ada  runtime  features  were 
important  for  real-time  embedded  systems.  This  process  involved 
prioritizing  Ada  RTE  elements  by  the  implementation  of  a  prioritization 
matrix.  The  prioritization  matrix  was  demonstrated  by  prioritizing  RTE 
elements  for  COMINT/ELINT  systems.  The  prioritization  matrix  was  designed 
so  it  could  be  applied  to  any  class  of  real-time  embedded  systems  with  only 
slight  modifications. 

The  prioritized  RTE  elements  were  used  to  prioritize  groups  of 
benchmarks.  This  provided  software  developers  with  a  prioritized  list  of 
groups  of  benchmarks  that  measure  the  critical  areas  of  candidate  RTEs  being 
considered  for  COMINT/ELINT  systems.  j  ^ 

The  concept  of  a  composite  benchmark  vas  developed  as  another  means  to 
test  candidate  RTEs.  Unlike  most  existing  benchmarks,  a  composite  benchmark 
takes  into  account  the  interactions  and  interfaces  that  go  on  within  a 
system.  A  preliminary  composite  benchmark  description  vas  developed  for 
COMINT/ELINT  systems . 

When  selecting  an  RTE,  the  composite  benchmark  would  be  used  to  test 
the  minimvus  threshold  of  RTEs.  Then,  the  prioritized  groups  of  benchmarks 
would  be  used  to  test  the  critical  RTE  elements  to  determine  which  RTEs 
perform  best  in  the  critical  areas. 
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1.1  BACKGROUND 

Since  the  early  implementation  of  the  Ada  language,  Ada  compilers  were 
required  to  pass  a  validation  test.  Thus,  the  primary  goal  of  compiler 
vendors  was  to  have  their  compiler  pass  this  validation  test.  This  left 
performance  as  a  secondary  issue.  In  addition,  the  Department  of  Defense 
(DOD)  mandates  the  use  of  Ada  in  the  development  of  real-time  embedded 
systems.  With  206  validated  compilers  (and  the  list  continues  to  grow), 
software  developers  must  be  able  to  obtain  guidance  in  the  selection  of  a 
compiler  and  its  runtime  environment  (RTE)  to  ensure  all  the  strict  timing 
and  storage  requirements  of  real-time  embedded  systems  are  met. 

To  provide  this  guidance  requires  the  identification  of  Ada  RTE 
features  of  interest  for  real-time  embedded  systems.  This  involves  two 
steps:  first,  the  Ada  nintime  features  that  are  important  for  real-time 
systems  need  to  be  established;  second,  evaliiation  criteria  to  evaluate 
these  features  need  to  be  determined.  To  establish  the  important  Ada 
runtime  features,  the  Ada  RTE  elements  need  to  be  prioritized.  To  evaluate 
the  Ada  runtime  features,  current  benchmarks  must  be  prioritized  and  new 
benchmarks  developed. 

1.2  PURPOSES  OF  THIS  STUDY 

The  primary  purpose  of  this  study  was  to  assist  software  developers  in 
selecting  an  RTE  chat  meets  Che  performance  requirements  of  their 
application.  This  study  provides  a  process  that  a  developer  can  use  to 
prioritize  RTE  elements  for  a  particular  application  domain.  The 
prioritization  of  RTE  elements  provides  the  means  to  prioritize  benchmarks. 
S^nce  it  might  not  be  possible  for  a  developer  to  run  all  possible 
benchmarks,  a  listing  of  prioritized  groups  of  benchmarks  allows  developers 
CO  focus  on  the  most  critical  areas  of  a  specific  application  domain. 
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In  this  study  RTE  elements  were  prioritized  for  one  class  of  systems 
supported  by  U.S.  Army  Communications -Electronics  Command  (CECOH)  Ft. 
Monmouth,  NJ.  That  class  is  Communication  and  Electronic  Intelligence 
(COMINT/ELINT)  systems. 

Most  existing  benchmarks  test  one  RTE  element  in  isolation,  without 
consideration  of  the  effect  of  RTE  elements  interfacing.  To  measure  both 
the  specific  elements  of  interest  in  an  RTE,  as  well  as  any  interaction 
effects,  required  a  new  type  of  benchmark. 

One  major  result  of  this  study  was  t!:e  formulation  of  a  composite 
benchmark  that  tests  RTE  elements  and  their  interactions.  A  composite 
benchmark  i.<!  defined  as  a  prototype  of  the  capabilities  of  a  particular 
class  of  ^system.  The  goal  of  a  composite  benchmark  is  to  test  the  minimum 
threshold  of  all  candidate  RTEs.  This  study  developed  preliminary  guidelines 
for  developing  a  composite  benchmark  and  a  preliminary  description  for  a 
composite  benchmark  for  COMINT/ELINT  systems. 

1.3  ORGANIZATION  OF  THIS .REPORT 

The  organization  of  this  report  reflects  the  order  in  which  the 
research  was  done.  In  the  first  step  (Section  2.0)  a  class  of  systems, 
COMINT/ELINT,  were  chosen  to  be  studied  and  the  capabilities  common  to 
COMINT/ELINT  systems  were  identified.  The  second  step  (Section  3.0) 
identified  what  Ada  constructs  would  be  used  to  implement  each  capability. 
The  third  step  (Section  A.O)  identified  which  RTE  element  would  be  used  to 
support  the  implementation  of  each  identified  Ada  construct.  The  forth  step 
(Section  5.0)  prioritized  the  Ada  RTE  elements  by  applying  a  prioritization 
matrix  to  the  RTE  elements.  The  fifth  step  (Section  6.0)  used  the 
prioritized  RTE  elements  to  prioritize  groups  of  benchmarks.  In  the  sixth 
step  (Section  7.0)  the  purpose  of  a  composite  benchmark,  the  development 
process  of  a  composite  benchmark,  and  a  preliminary  description  of  a 
composite  benchmark  are  given.  The  last  step  (Section  8.0)  recommends  how 
benchmarks  are  to  be  used  in  the  RTE  selection  process. 


2 


The  first  step  in  this  research  was  to  select  specific  real-time 
systems  to  study.  The  goal  of  the  selection  process  was  to  identify  a  class 
of  systems  supported  by  CECOM  that  are  the  most  challenging  to  develop  and 
maintain  and  then  to  select  representative  systems  from  that  class.  The 
most  challenging  class  of  systems  was  the  class  with  the  greatest  number  of 
large,  real-time  systems.  Once  the  class  was  identified,  sample  systems 
were  chosen.  It  would  have  been  impractical  to  study  all  of  the  systems 
because  of  the  system  diversity  and  the  number  of  systems . 

At  the  time  the  research  was  performed  for  this  report,  CECOM  supported 
140  systems.  CECOM  classified  their  systems  into  five  Bacclefield 
Functional  Areas  (BFA) ,  and  each  BFA  was  divided  into  its  own  set  of 
categories.  Individual  systems  were  placed  into  categories  within  each 
BFA.  Figure  2-1  shows  a  diagram  of  the  classification  scheme. 

Battlefield  Functional  Area  (BFA) 

Category 

System  _______ 

Figure  2-1.  The  Classification  Scheme. 

CECOM  supports  the  following  BFAs . 

1.  Intelligence  Electronic  Uarfare  (lEV) 

2.  Fire  Support  (FS) 

3.  Maneuver  Control  (MC) 

4.  Communications  (COMM) 

5 .  Air  Defense  (AD) . 

The  initial  data  set  contained  Information  on  136  systems;  however, 
only  56  of  the  systems  have  enough  information  on  them  to  adequately 
analyze.  Therefore,  the  initial  analysis  was  done  on  these  56  systems. 
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The  seleccion  process  involved  three  sceges.  First,  the  real-time 
systems  in  the  data  set  were  identified;  second,  the  class  of  systems  with 
the  greatest  nximber  of  large  real-time  systems  was  determined;  and  third, 
specific  systems  within  the  chosen  class  were  selected. 

2.1  REAL-TIME  SYSTEMS  IDENTIFICATION 

Real-time  software  constantly  monitors,  analyzes,  and  responds  to 
external  physical  events  in  a  time-critical  fashion.  The  high-level 
functions  performed  by  real-time  systems  are  as  follows; 

1.  Monitor  -  connection  o^  a  physical  event  to  a  computer 

system  so  that  data  pertaining  to  the  physical  event  can  be  collected. 

2.  Analyze  •  portion  of  software  that  determines  the  next  course  of  action 
based  on  the  data  collected. 

3.  Respond  -  portion  of  software  that  executes  the  course  of  action 
determined  from  the  analysis. 


Real-time  systems  perform  one  or  more  of  these  high-level  functions  and 
must  also  be  time  critical  in  that  the  failure  to  monitor,  analyze,  and 
respond  in  a  timely  manner  would  be  disastrous. 

To  determine  which  CECOM  systems  were  real-time  systems,  the  functions 
that  each  system  performs  were  compared  to  the  three  high-level  functions 
listed  above.  If  CECOM  systems  implemented  one  or  more  of  these  high-le' el 
functions  and  the  function  were  time -critical,  the  system  was  deemed  to  be  a 
real-time  system. 

TABLE  2-1  classifies  the  functions  performed  by  CECOM  systems  according 
to  the  high-level  functions  they  implement.  All  the  functions  were 
determined  to  be  time -critical.  A  description  of  each  function  is  found  in 
Appendix  A. 
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TABLE  2-1 

System  Functions  By  the  High-Level  Fxanctions  They  Implement 


receiver 
reception 
target  detection 


Analyze 

direction  finding 

analysis 

location 


Respond 

transmitter 
countermeasure 
antenna  controller 


2.2  CLASS  SELECTION 

After  determining  what  CECOM  systems  were  real-time  systems,  the  next 
step  was  to  pick  a  particular  class  of  CECOM  systems  to  study.  The 
objective  was  to  choose  a  class  of  systems  Chat  had  the  largest  number  of 
large  real-time  systems.  Because  CECOM  already  classified  systems  into  BFAs 
and  categories,  the  objective  was  to  choose  a  BFA  and  category  chat 

contained  the  largest  number  of  real-time  systems,  TABLE  2-2  shows  the 
number  of  real-time  systems  in  each  BFA. 

TABLE  2-2 

Number  of  Real-Time  Systems  in  Each  BFA 

BFA  Number  of  Real-Time  Systems 

lEW  14 

FS  3 

MC  1 

COMM  5 

AD  5 


lEW  was  chosen  as  the  BFA  to  be  studied  because  it  contained  the  most 
large  real-time  systems.  The  lEW  category  of  Communication  Intelligence  and 
Electronic  Intelligence  (COMINT/ELINT)  contained  more  real-time  systems  chan 
any  ocher  lEW  category;  therefore,  it  was  selected  to  be  studied. 
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The  last  stage  was  to  select  specific  systems  to  study  that  were 
representative  of  COMINT/ELINT  systems.  An  assumption  was  made  that  if  a 
method  could  be  developed  to  prioritize  RTE  elements  for  large  systems,  the 
method  could  be  applied  to  smaller  types  of  real-time  systems. 

Four  COMINT/ELINT  systems  were  selected  to  represent  all  COMINT/ELINT 
systems;  Improved  Guardrail  V  (IGRV),  Advanced  Quicklook  (AQL) , 

Communication  High  Accuracy  Airborne  Location  System  (CHAALS) ,  and 
Trailblazcr  B.  Three  of  these  systems  are  part  of  the  Guardrail  Common 
Sensor  Family,  which  contains  the  largest  systems  within  lEW. 

IGRV  was  chosen  for  the  following  reasons: 

1.  It  is  the  largest  system  in  the  COMINT  category. 

2.  It  is  delivered  and  operational, 

3.  It  Is  a  real-time  embedded  system. 

i*.  It  is  a  part  of  the  Guardrail  Common  Sensor  Family. 

AQL  was  chosen  for  the  following  reasons; 

1.  It  is  the  second  largest  system  in  the  ELINT  category. 

2.  Modifications  to  it  are  being  made  in  Ada. 

3.  It  is  a  real-time  embedded  system. 

4.  It  is  part  of  the  Guardrail  Common  Sensor  Family. 

CHAALS  was  chosen  for  the  following  reasons: 

1.  It  is  the  second  largest  system  in  the  COMINT  category. 

2.  Although  not  delivered,  and  thus  not  operational,  its  preliminary 
design  is  in  Ada  Program  Design  Language  (PDL). 

3.  It  is  a  real-time  embedded  system. 

4.  It  is  part  of  the  Guardrail  Common  Sensor  Family. 


TralXblazer  B  was  chosen  for  Che  following  reasons: 

1.  Ic  is  Che  chlrd  largesc  sysceo  in  Che  COMINT  cacegory. 

2.  Ic  is  a  real'Clne  embedded  syscem. 

3.  The  syscem  is  delivered  and  operacional. 
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3.0  MAPPING  SYSTEM  CAPABILITIES  TO  ADA  CONSTRUCTS 

Each  capability  of  COMINT/ELINT  systems  was  mapped  to  the  Ada 
constructs  that  would  be  used  to  Implement  that  particular  capability.  The 
objective  of  this  was  to  determine  what  Ada  constructs  would  be  used  to 
implement  the  selected  class  of  real*cime  embedded  systems.  The  results 
were  that  all  Ada  constructs  would  be  used  in  one  of  these  systems.  Also, 
no  Ada  construct  could  be  determined  to  be  more  important  chan  any  ocher  Ada 
construct  because  most  constructs  would  be  used  throughout  real-time 
systems.  Because  of  this,  Che  results  of  this  step  had  no  significance  in 
the  prioritization  of  RTE  elements. 

The  system  capabilities  were  mapped  to  both  micro  and  macro  constructs. 
For  clarity,  a  discussion  of  system  capabilities  and  the  definition  of  a 
construct  will  be  presented  before  the  actual  matrices. 

3.1  SYSTEM  CAPABILITIES 

The  system  capabilities,  i.e.,  intercept,  direction  finding,  emitter 
location,  analysis,  and  reporting,  were  found  to  be  common  throughout 
COMINT/ELINT  systems.  The  way  the  systems  specifically  performed  a 
particular  capability  might  be  different,  but  the  overall  objective  was  the 
same.  Two  systems  that  rely  on  ocher  systems  to  perform  one  of  the 
capabilities.  For  example,  CHAALS  relies  on  IGRV  to  perform  its 
interception. 

Because  of  Che  amount  of  effort  required  to  perform  an  in-depth 
analysis  to  obtain  base  line  Ada  constructs,  one  COMINT/ELINT  system  was 
studied  in  detail.  This  analysis  was  performed  by  decomposing  high-level 
system  capabilities  into  low-level  system  capabilities  and  mapping  these 
low-level  capabilities  to  Ada  constructs.  Once  the  base  line  set  of 
constructs  was  developed  for  one  system,  it  was  validated  by  comparing  to 
the  low-level  capabilities  of  other  systems  in  the  same  category  to  those  of 
the  system  studied  in  detail.  Four  COMINT/ELINT  systems  were  used  to 
generate  the  Ada  constructs.  One  system  was  used  to  establish  the  base 
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line,  and  che  ocher  chree  systems  were  used  Co  validate  che  base  line 

constructs . 

3.2  ADA  CONSTRUCT  DEFINITION 

While  performing  a  preliminary  review  of  the  systems,  it  became  obvious 
chat  'construct'  needed  to  be  defined.  Two  definitions  were  appropriate; 
one  for  a  micro  construct  and  one  for  a  macro  construct.  At  che  micro 

level,  a  construct  was  defined  as  an  individual  Ada  statement.  At  the  macro 
level,  a  construct  was  defined  as  a  sec  of  Ada  statements  that  performs  a 
well  defined  process.  For  this  research,  both  micro  and  macro  constructs 
were  studied. 

3.3  ADVANTAGES  AND  DISADVANTAGES  OF  MICRO  AND  MAC^O  CONSTRUCTS 

The  use  of  either  macro  or  micro  constructs  has  its  respective 

advantages  and  disadvantages.  The  advantage  of  benchmarking  micro 
constructs  is  that  they  are  specific  to  each  individual  Ada  stacemenc,  and 
therefore,  each  statement  can  be  benchmarked.  The  disadvantage  of 
benchmarking  micro  constructs  is  that  interactions  of  individual  statements 
when  used  for  a  particular  application  are  ignored.  Benchmarking  only  micro 
constructs  is  unrealistic  compared  to  how  Ada  code  is  written.  The 

advantage  of  benchmarking  macro  constructs  is  chat  they  take  into  account 
che  blending  and  interaction  of  Ada  statements.  Macro  constructs  are 
realistic  to  how  Ada  code  is  actually  used.  The  disadvantage  of 
benchmarking  macro  constructs  is  that  they  are  only  as  good  as  che  match 
between  Che  benchmark  run  and  che  actxial  application  code.  The  benchmark  is 
some  generic  code  used  to  carry  out  a  particular  process.  If  che  actual 
application  cods  varies  from  che  generic  code,  che  benchmark  might  not  be 
valid. 

3.4  SYSTEM  CAPABILITIES  VS.  ADA  CONSTRUCT  MATRIX 

Figure  3'1  presents  che  mapping  of  che  system  capabilities  to  che  base 
line  macro  constructs.  Figure  3*2  presents  che  mapping  of  system 
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capabilities  to  the  base  line  micro  constructs  More  information  on  how  the 
Ada  constructs  were  identified  is  provided  in  Appendix  B. 
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Figure  3-1.  System  Capabilities  Vs.  Macro  Construct  Matrix. 
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Figure  3*2.  System  Cepabllicles  Vs.  Micro  Construct  Matrix. 
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Each  Ada  conscrucc  was  mapped  co  che  Ada  RTE  elements  that  would  be 
used  CO  manage  Che  Implemencaclon  of  chac  particular  construct.  A 
description  of  each  of  the  RTE  elements  is  provided  in  Appendix  C  [ARTEVG 
1988].  The  objective  of  this  step  was  to  determine  which  of  che  11  RTE 
elements  were  not  important  for  the  class  of  real-time  embedded  systems 
being  studied.  The  results  were  that  every  RTE  element,  except  target 
housekeeping,  had  an  Ada  construct  directly  mapped  to  it;  therefore,  it  was 
assumed  that  every  RTE  element  was  important  except  target  housekeeping. 
The  next  step  was  to  determine  which  of  che  remaining  10  RTE  elements  were 
che  most  important.  A  prioritization  matrix  (See  Section  5.0)  was 
developed.  The  implementation  of  this  matrix,  contradicted  the  earlier 
finding  of  this  step  chac  target  housekeeping  was  not  important.  As  a 
result  of  che  matrix  implementation,  target  housekeeping  was  deemed  to  be 
important;  therefore  it  was  considered  in  this  study. 

4.1  ADA  CONSTRUCT  VS.  ADA  RTE _ELE.MENT.S_  MATRIX 

The  matrix  that  maps  Ada  macro  constructs  to  che  Ada  RTE  elements  is 
shown  in  Figure  4-1.  The  matrix  chac  maps  Ada  micro  constructs  co  che  Ada 
RTE  elements  is  shown  in  Figure  4-2. 

4.2  THE  REASONING  FOR  MAPPING  A  P.ARTICUU^  ADA  CONSTRUCT  TO  A 
PARTICULAR  RTE  ELEMENT 

A  discxission  of  each  identified  Ada  conscrucc  and  why  it  is  mapped  to 
che  particular  RTE  element  is  presented  in  the  following  subsections .  One 
element,  target  housekeeping,  had  no  Ada  constructs  mapped  to  it. 

4.2.1  Dynamic  Memory  Management 


The  micro  construct  chac  maps  to  dynamic  memory  management  and  che  Ada 
statement  chac  allocates  memory  are  indicated  by  che  reserved  word,  NEU. 
For  deallocation,  Ada  performs  its  own  'garbage  collection'.  Memory  can  be 
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cleared  deliberacely  by  using  unchecked  deallocation.  The  dynamic  memory 
function  can  also  raise  a  storage  error,  if  a  request  for  storage  cannot  be 
fulfilled.  The  macro  constructs  that  were  mapped  to  the  dynamic  memory 
function  are  queues  and  stacks.  Both  of  these  constructs  dyn£unically 
allocate  or  deallocate  memory  when  they  add  or  remove  data  from  their 
structure. 

4.2.2  Processor  Manaeement 

The  execution  and  scheduling  of  the  micro  construct,  task,  is  closely 
related  to  the  processor  management  function.  The  processor  management 
function  implements  the  assignment  of  physical  processors  to  tasks  that  are 
logically  executing.  The  micro  construct,  priority,  is  used  to  assist  the 
processor  management  function  in  determining  which  task  is  to  be  assigned  to 
the  processor  next.  The  macro  constructs  that  were  identified  for  processor 
management  are  the  mailbox  and  the  semaphore.  Both  of  these  constructs 
involve  the  use  of  tasks  within  their  implementation. 

4.2.3  Interrupt  Management 

The  micro  construct,  interrupt,  identified  in  Chapter  13  of  the 
Reference  Manual  for  the  Ada  Programming  Language  [ANSI/MIL-STD-181SA-1983] , 
is  used  for  the  interrupt  management  function.  Interrupt  is  used  to  react 
to  asynchronous  events.  The  address  clause  has  been  identified  because  it 
is  used  to  access  a  particular  hardware  address  to  initiate  an  interrupt. 

U.i.U  lim?.  «,gh?Rgm$ng 

The  two  micro  constructs  used  in  the  time  management  function  are  the 
delay  statement  and  the  clock.  Time  management  is  the  portion  of  the  RTE 
chat  supports  the  predefined  package.  Calender.  The  time  management 
function  cooperates  with  the  rendezvous  management  function  Co  implement 
timed  entry  calls  and  selective  waits  with  delay  alternatives . 
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The  micro  construct ,  exception,  was  identified  for  the  exception 
management  function.  Exception  management  implements  the  Ada  semantics  for 
raising  exceptions  and  determines  if  there  is  a  matching  handler  for  a 
raised  exception.  The  memory  allocation/deallocation  operation  was  also 
identified.  It  is  responsible  for  initiating  a  storage  error  exception  if  a 
request  to  allocate  memory  cannot  be  performed. 

4.2.6  Rendezvous  Management  Task  Activation  Task  Termination 


Rendezvous  management,  task  activation,  and  cask  termination  are 
concerned  with  the  micro  construct,  cask.  Rendezvous  management  implements 
the  semantics  of  the  Ada  rendezvous  concept.  Rendezvous  management  also 
concerns  itself  with  the  micro  construct,  selection  criteria,  which  is  used 
within  a  cask.  Task  activation  allows  the  dynamic  creation  of  casks.  Task 
termination  includes  the  sec  of  rules  for  completion,  termination,  and 
abortion  of  casks.  The  macro  constructs  mapped  to  these  three  elements  are 
the  mailbox  and  the  semaphore.  These  were  identified  because  they  use  casks 
within  their  implementation.  Tasks  were  chosen  for  their  implementation 
because  of  the  need  for  concurrent  processing  in  real-time  systems. 

4.2.7  Input/Oucput  (I/O)  Management  Function 

The  micro  construct  identified  for  the  I/O  management  function  is  the 
address  clause.  The  address  clause  is  used  for  low- level  I/O  to  communicate 
wich  physical  devices. 

4.2.8  Commonly  Called  Code  Sequences 

Commonly  called  code  is  the  catch-all  for  the  remaining  micro 
constructs:  procedure  calls,  function  calls,  assignment  statements,  and 
control  statements.  All  of  the  macro  constructs  were  mapped  to  the  commonly 
called  sequences  because,  if  the  constructs  were  included  as  a  RTE 
predefined  subroutines,  they  would  be  included  under  this  function. 


k2.9  Target  Housekeeping  Functions 

No  micro  or  macro  constructs  were  mapped  directly  to  the  target 
housekeeping  functions. 
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0  STRUCTURE 


F  THE  RTE  ELEMENT  PRIORITIZATION  MATRIX 


The  Initial  plan  for  this  research  called  for  mapping  system 
capabilities  to  the  Ada  constructs  that  would  be  used  to  implement  them. 
These  constructs  would  then  be  mapped  to  the  Ada  RTE  elements  necessary  to 
support  them.  As  Section  3.0  and  4.0  indicate,  the  diversity  of  Ada 
statements  necessary  to  implement  particular  characteristics  of  the  class  of 
systems  studied  precluded  using  this  approach  to  prioritize  RTE  elements.  A 
new  strategy  was  devised.  The  requirements  for  the  selected  systems  were 
mapped  to  six  basic  features  of  real-time  embedded  systems.  The  11  RTE 
elements  were  then  prioritized  based  on  their  importance  in  implementing  the 
six  basic  features.  The  key  to  this  process  was  the  use  of  a  prioritization 
matrix.  The  remainder  of  this  section  details  the  development  of  this 
matrix  and  its  implementation,  i.e.,  prioritizing  the  RTE  elements.  The 
columns  of  the  matrix  are  the  six  basic  features  of  real-time  embedded 
systems,  and  the  rows  are  the  11  RTE  elements. 

S.l  THE  SIX  EMBEDDED  COHPUTER  SYSTEM  fECS)  FEATURES 

The  Software  Engineering  Institute  (SEI)  determined  that  there  are  six 
basic  features  of  an  embedded  real-time  system:  time  control,  concurrent 
control,  I/O  control,  error  handling,  numeric  computations,  and  internal 
representation  [Veiderman  1987A} .  The  six  features  were  developed  by  SEI 
from  the  definition,  the  general  requirement,  and  the  basic  characteristics 
of  embedded  computer  systems. 

To  implement  the  prioritization  matrix,  each  of  the  features  has  a 
weight  assigned  to  it.  The  weights  represent  the  relative  importance  of  an 
ECS  feature  with  respect  to  the  class  of  systems  being  studied.  Each  of  the 
six  features  is  given  a  weight,  and  the  sum  of  the  weights  equal  100%.  The 
100%  signifies  an  entire  system  within  the  class  under  study,  and  the 
separate  weights  indicate  the  importance  of  each  feature  to  any  system  in 
that  class  of  systems.  The  weights  should  not  change  as  one  moves  from  one 
system  to  another,  provided  one  looks  at  systems  in  only  one  class.  If  the 
class  of  systems  is  changed,  the  weights  will  change. 
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Deceraining  the  weights  for  the  COMINT/ELINT  class  involved  r~'o  steps. 
The  first  was  to  understand  which  features  were  important  and  to  begin  to 
quantify  their  importance  by  studying  the  system  requirements.  For  this 
study  each  requirement  was  mapped  to  the  particular  ECS  feature  to  which  it 
pertained.  This  step  resulted  with  the  majority  of  the  requirements  mapped 
to  I/O  control. 

This  first  step  gave  an  indication  of  which  features  were  important  and 
a  number  from  which  the  feature  could  be  assigned  a  weight;  however,  it  did 
not  take  into  account  issues  that  effect  the  performance  of  a  system.  The 
primary  concerns  with  respect  to  system  performance  were  concurrent  control 
and  time  control.  The  requirements  may  define  the  need  for  concurrency,  but 
they  do  not  represent  the  solution,  which  is  the  algorithm  that  is  used  to 
meet  concurrency  needs.  Also,  the  requirements  may  define  the  time  limits 
imposed  on  the  system,  but  they  do  not  reflect  the  stringency  of  chose 
limits . 

Step  two  was  to  adjust  the  weights  by  studying  the  requirements  and 
determining  their  effect  on  the  performance  of  the  systems.  Then,  taking 
into  account  the  results  of  steps  1  and  2,  the  weights  were  subjectively 
assigned  to  each  ECS  feature  (see  Table  5.1).  A  detailed  discussion  of  the 
distinct  characteristics  of  COMINT/ELINT  systems  chat  lead  to  the  assignment 
of  the  final  weights  is  presented  in  Appendix  D. 

Table  5-1 

The  Final  Weights  Assigned  to  the  Features 


ZgagMLca 

Concurrent  Control 

20% 

Time  Control 

20% 

I/O  Control 

25% 

Error  Handling 

10% 

Numeric  Computation 

10% 

Internal  Representation 

15% 
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5.2 


The  rows  of  the  prioritization  matrix  are  the  11  RTE  elements  that  were 
obtained  from  the  document  *A  Framework  For  Describing  The  Ada  Runtime 
Environment”  [ARTEVG  1988].  These  RTE  elements  are  the  following: 


Memory  Management 
Processor  Management 
Interrupt  Management 
Time  Management 
Exception  Management 
Rendezvous  Management 
Task  Activation 
Task  Termination 
I/O  Management 

Commonly  Called  Code  Sequences 
Target  Housekeeping. 


A  detailed  description  of  each  RTE  element  can  be  found  in  Appendix  C. 
The  RTE  elements  make  up  the  rows  for  Che  prioritization  matrix.  These 
elements  are  assigned  rates.  The  races  are  for  quantifying  the  effect  that 
an  RTE  element  has  on  Che  performance  of  an  ECS  feature.  Racing  an  element 
against  an  ECS  feature  is  independent  of  the  class  of  systems  of  interest. 

A  racing  scale  is  used  to  race  an  element.  The  scale  shown  below  was 
used  in  this  prioritization  matrix.  Following  the  scale,  each 
classification  is  defined. 

Intrinsic  -  9 
Supportive  -  5 
Extrinsic  -  1 

Intrinsic  is  defined  as  an  RTE  element  chat  is  foundational  to  the 
performance  of  a  particular  feature. 

Supportive  is  defined  as  an  RTE  element  that,  although  not  intrinsic, 
has  a  role  in  the  performance  of  a  particular  feature. 


21 


Extrinsic  is  defined  as  an  RTE  element  that  has  at  most  a  minor  role  in 
the  performance  of  the  particular  feature. 

Two  documents  were  influential  in  the  racing  process :  the  ARTEWG 
doctifflenc,  "A  Framework  for  Describing  Ada  Runtime  Environments"  [ARTEWG 
1988]  and  the  SEI  document,  "Ada  for  Embedded  Systems:  Issues  and  Questions" 
[Ueiderman  1987A] .  The  rating  process  involved  concentrating  on  one  ECS 
feature  to  determine  whether  an  RTE  element  was  intrinsic  to  the  performance 
of  the  feature.  If  it  was,  a  '9*  was  entered  into  the  square.  If  it  was 
not,  the  RTE  element  was  determined  to  be  either  supportive  or  extrinsic.  A 
detailed  discussion  of  each  rating  decision  is  presented  in  Appendix  E. 

5.3  APPLICATION  OF  THE  RTE  PRIORITIZATION  MATRIX 

After  all  the  weights  and  races  had  been  determined  the  next  step  was 
CO  multiply  Che  weights  by  the  races.  This  step  integrated  all  of  the 
components  of  the  prioritization  matrix:  the  ECS  features,  their  relative 
importance  to  the  class  of  systems  (the  weight),  and  the  RTE  elements' 
racings . 

The  last  step  was  to  sum  all  the  products  in  a  given  row.  The  result 
was  a  prioritized  list  of  RTE  elements.  The  element  with  the  highest  total 
for  a  row  was  Che  most  critical  element,  and  the  element  with  the  next 
highest  was  the  next  most  critical,  and  so  on. 

5.4  THE  MATRIX  APPLIED  TO  THE  COMINT/ELINT  CIASS 

Figure  5.1  presents  the  prioritization  matrix  for  COMINT/ELINT  systems. 
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The  following  li:;t  Is  the  prioritized  list  of  RTE  elements. 


1.  Memory  management  .  700 

2.  Time  management . 660 

3.  I/O  management . S40 

4.  Processor  management  .  560 

5.  Rendezvous  management . 560 

6.  Exception  management  .  540 

7 .  Interrupt  management . 500 

8 .  Task  Activation . 380 

9.  Task  Termination . 380 

10.  Target  Housekeeping . 380 


11.  Commonly  Called  Code  Sequences  280 

This  list  of  prioritized  RTE  elements  is  the  driver  for  prioritizing  groups 
of  benchmarks. 
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6.0 


There  is  a  very  large  miaber  of  available  RTE  benchmarks.  Hose  of 
these  benchmarks  evaluate  a  single  RTE  element.  Choosing  which  of  the 
available  benchmarks  would  be  the  most  relevant  for  a  particular  application 
domain  requires  both  prioritizing  the  RTE  elements  and  mapping  the  existing 
benchmarks  to  the  RTE  elements.  Each  element,  therefore,  has  a  group  of 
benchmarks  mapped  to  it.  Th\is,  it  is  these  groups  of  benchmarks  that  have 
been  prioritized,  not  the  individual  benchmarks. 

Section  S.O  detailed  the  prioritization  of  RTE  elements  for 
COMINT/ELINT  systems.  This  section  provides  the  mapping  of  benchmarks  to 
RTE  elements . 

6.1  HAPPING  BENCHMARKS  TO  RTE  ELEMENTS 

The  majority  of  the  benchmarks  listed  here  came  from  the  dociusent 
"Real-Time  Performance  Benchmarks  for  Ada"  [Coel  1988].  The  ocher 
benchmarks  came  from  the  Performance  Issues  Working  Group  [1988].  The  Ada 
Compiler  Evaluation  Capability  (ACEC)  (Leavitt  1988]  benchmarks  were  not 
included  in  this  study  because  of  disclosure  restrictions.  The  format  In 
which  the  benchmarks  are  presented  and  the  numbers  assigned  to  benchmarks 
were  taken  from  their  source.  This  has  been  done  so  that  an  Individual  can 
go  back  to  the  source  document  to  obtain  more  information  about  a  specific 
benchmark.  The  complete  list  of  all  the  RTE  elements  and  the  prioritized 
groups  of  benchmarks  is  found  in  Appendix  F. 

For  the  purpose  of  mapping  benchmarks  to  the  RTE  elements,  two  elements 
have  been  combined:  task  activation  and  task  termination.  This  was  done 
because  Che  benchmarks  chat  measure  these  two  elements  are  similar,  and  the 
RTE  elements  have  the  same  prioritization  level. 

Table  6-l  shows  the  priority  order  of  the  groups  and  the  number  of 
benchmarks . 
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TABLE  6-1 

Priority  of  Benchmarks 


KIL 

1. 

tiements 

Memory  Management 

2. 

Time  Management 

4 

3. 

I/O  Management 

1 

6. 

Processor  Management 

5 

5. 

Rendezvous  Management 

22 

6. 

Exception  Management 

12 

7. 

Interrupt  Management 

6 

8. 

Task  Activation/Termination 

12 

9. 

Target  Housekeeping 

0 

10. 

Commonly  Called  Code  Sequences 

51 

6.2 

To  give  the  user  a  more  thorough  understanding  of  exactly  what  a 
benchmark  measures,  e.g.,  memory  space  or  response  time,  the  benchmarks  were 
subdivided  into  types.  It  was  determined  that  there  were  three  types  of 
benchmarks;  timing  benchmarks,  storage  benchmarks,  and  if>and>hov 
benchmarks.  The  first  two  types  measure  the  two  critical  resources  of  an 
embedded  system,  i.e.,  response  time  and  memory  space.  The  third  type,  lf> 
and  how  benchmarks,  address  the  need  to  determine  how  an  RTE  will  respond 
given  a  set  of  conditions.  The  benchmarks  reveal  choices  compiler  vendors 
make  when  developing  their  RTE  by  determining  if  an  RTE  will  implement  a 
specific  feature  or  how  an  RTE  implements  something.  For  example,  a 
Processor  Management  benchmark,  determine  if  user  tasks  are  preemptive,  will 
reveal  how  scheduling  strategies  were  implemented  by  a  particular  vendor. 
If-and-how  benchmarks  will  also  be  used  to  determine  whether  a  particular 
feature  is  provided  by  a  vendor,  e.g.,  determine  if  unchecked  deallocation 
is  implemented. 


6.2.1 


Because  of  possible  confusion,  a  distinction  between  time  management 
and  timing  benchmarks  needs  to  be  made.  Benchmarks  that  measure  aspects  of 
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time  management  pertain  to  Ada  features  that  are  time  related,  e.g.,  Measure 
CLOCK  function  overhead,  Measure  CLOCK  resolution.  Timing  benchmarks  relate 
to  all  those  benchmarks  that  measure  the  length  of  time  it  takes  for  an 
event  to  occur,  e.g.,  overhead  time,  time  to  store  data,  etc.  Thus,  if  one 
is  concerned  with  measuring  the  overall  timing  performance  of  an  RTE,  one 
should  use  timing  benchmarks. 

6.2.2  The  Frequency  of  Commonly  Called  Code  Sequence  Benchmarks 

Commonly  Called  Code  Sequences  had  the  most  benchmarks,  51,  mapped  to 
it.  ARTEUG  describes  this  element  as  some  what  of  a  "catch-all"  that 
includes  runtime  routines  in  the  classical  sense,  e.g.,  multi-word 
arithmetic,  block  moves,  and  string  operations.  The  types  of  benchmarks 
included  in  this  group  were  procedure  and  fxinction  calls,  addition,  and 
anything  that  had  code  added  (or  removed,  as  with  pragma  PACK)  by  the 
compiler.  Also  included  in  this  category  were  "code  sequences"  written  by 
the  user.  Vhlle  investigating  the  four  systems,  some  code  sequences 
resurfaced,  e.g.,  matrix  manipulation,  trig  functions,  and  message  passing 
routines .  All  of  these  were  put  in  the  Commonly  Called  Code  Sequences . 

6.3  BENCHMARKS  THAT  NEED  TO  BE  DEVELOPED 

Once  the  benchmarks  were  mapped  to  the  RTE  elements ,  it  became  evident 
that  some  elements  are  not  adequately  addressed  by  benchmarks.  It  was 
determined  that  there  is  a  need  for  additional  benchmarks  that  evaluate  some 
RTE  elements.  In  some  instances  this  need  is  because  of  an  overall  lack  of 
benchmarks;  in  other  instances,  even  with  several  benchmarks,  others  are 
needed.  The  elements  in  need  of  additional  benchmarks  are  I/O  Management, 
Processor  Management,  Target  Housekeeping  and  Commonly  Called  Code 
Sequences . 

Benchmarks  need  to  be  developed  for  I/O  Management.  During  the  course 
of  the  study,  it  was  determined  that  for  the  COMINT/ELINT  systems  I/O  is 
critical  to  system  performance.  With  only  one  benchmark,  it  is  difficult  to 
determine  an  RTE's  I/O  performance. 
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More  benchmarks  need  to  be  developed  for  Processor  Management. 
Software  developers  must  be  able  to  determine  courses  of  action  taken  by 
tasks  in  order  that  they  might  develop  reliable  programs.  More  if-and*how 
benchmarks  would  reveal  to  the  software  developer  courses  of  actions 
implemented  by  the  RTE. 

Target  Housekeeping  is  "associated  with  the  actions  starting  up  and 
terminating  the  execution  environment  of  an  Ada  program”  [ARTEVG  1988].  In 
one  of  the  systems  studied  there  is  a  requirement  for  the  system  to  be  up 
and  running  from  a  cold  start  in  10  minutes.  This  indicates  chat  start  up 
is  critical,  and  thus  benchmarks  are  needed  to  measure  this  element. 

During  the  study  of  the  four  COHIMT/ELINT  systems,  a  number  of 
'algorithms'  resurfaced.  For  example,  each  system's  software  solution 
frequently  used  matrix  manipulations,  trig  functions,  message  transmission 
facilities,  etc.  Benchmarks  for  these  'algorithms’  would  be  beneficial  to 
the  individuals  selecting  the  compiler  and  RTE.  These  additional  benchmarks 
would  be  mapped  to  the  RTE  element  Commonly  Called  Code  Sequences. 
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The  majority  of  benchmarks  available  either  test  a  specific  element  of 
the  RTE  in  isolation  or  exercise  several  elements  in  some  unspecified 
combination.  What  is  needed  is  a  single  benchmark  that  tests  elements  of  an 
RTE  while  interacting  in  a  manner  that  is  consistent  with  their  interaction 
during  actual  system  operation.  Such  a  benchmark  would  evaluate  an  Ada  RTE 
by  forcing  the  RTE  to  perform  operations  chat  would  mirror  the  operations 
performed  by  the  system  to  be  developed. 

7.1  PURPOSE  OF  A  COMPOSITE  BENCHMARK 

A  composite  benchmark  is  a  model  of  the  capabilities  of  a  particular 
class  of  systems.  The  purpose  of  a  composite  benchmark  is  to  stress  a 
computer  and  its  RTE  to  evaluate  their  ability  to  perform  the  capabilities 
of  a  particular  class  of  systems. 

A  composite  benchmark  allows  a  software  developer  to  run  one  benchmark 
that  will  give  him  a  general  idea  of  whether  a  particular  RTE  can  perform 
the  capabilities  of  a  given  class  of  systems.  A  composite  benchmark  tests 
each  capability  individually  and,  more  importantly,  the  interaction  among 
the  capabilities. 

7.2  HOW  TO  DEVELOP  A  COMPOSITE  BENCHMARK 

Developing  a  composite  benchmark  description  for  a  particular  class  of 
systems  is  not  a  simple  task,  but  once  developed  the  benchmark  could  be  used 
to  aid  in  the  selection  of  an  RTE  for  any  system  in  the  given  class.  The 
following  three  steps  should  be  followed  when  developing  composite 
benchmarks ; 

1.  Identify  the  common  capabilities  of  the  particular  class  of  systems  by 
studying  the  requirements  and  functions  of  the  systems  within  the 
class . 

2.  Define  and  analyze  each  capability.  The  description  should  include  all 
functions  common  to  the  systems  in  the  class.  If  a  particular  function 
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is  common  Co  several  of  the  systems  within  the  class,  it  should  be 
Included  in  the  description  because  the  function  may  be  performed  in  a 
new  system  being  developed. 


3.  Document  the  interactions  and  interfaces  among  the  capabilities  in  a 
format  that  facilitates  computer  program  code  development.  When 
writing  the  description,  there  needs  to  be  continuous  interaction 
between  Che  writer  and  computer  programmer  to  ensure  chat  the  composite 
benchmark  will  be  accurate  and  understandable.  The  description  writer 
must  have  an  ln>depch  technical  knowledge  of  Che  class  of  systems  being 
studied. 

7.3  COMPOSITE  BENCHMARK  FOR  COMTNT/ELINT  SYSTEMS 

A  description  for  a  preliminary  composite  benchmark  was  developed  in 
this  study  for  COMINT/ELIirr  systems.  The  goal  has  been  to  develop  the  idea 
and  an  approach  for  developing  a  composite  benchmark.  Because  of  this,  the 
composite  benchmark  being  developed  is  immature  and  needs  to  be  addressed 
more  directly  in  the  future.  The  preliminary  composite  benchmark  models  the 
five  capabilities  of  COMINT/EUNT  systems:  intercept,  direction  finding, 
emitter  location,  analysis,  and  reporting.  This  description  was  given  to 
another  company,  TaMSCO,  for  code  development. 


It  is  assumed  that  the  target  audience  of  the  composite  benchmark 
description  is  familiar  with  COMINT/ELINT  systems.  Terms  chat  may  not  be 
familiar  to  the  target  audience  are  defined. 


7.4  COMPOSITE  BENCH.M.^K  DESCRIPTION  FOR  COMINT/ELINT  SYSTEMS 


The  program  performance  specifications  docvimentation  and  the  program 
design  specifications  documentation  for  the  four  selected  COMINT/ELINT 
systems  (See  Section  2.0)  were  studied  to  obtain  the  information  used  in  the 
description. 


7.4.1  The  Incercepc  Capability 

The  benchmark  ntust  perform  aucomacic  acquisition  of  unknown  signals. 
It  will  search  frequency  bands  to  find  and  catalog  unknown  signals.  This 
involves  two  different  search  capabilities:  general  search  (GS)  and 
directed  search  (DS) . 

7. 4. 1.1  General  Search  (GS) 

GS  is  a  broad  based  sampling  of  frequency  activity.  It  monitors  a 
number  of  frequency  bands  for  emitter  activity  and  reports  the  occurrence  of 
detected  signals.  This  involves  automatic  environment  mapping  within 
selected  frequency  bands  with  associated  geographic  areas  of  interest  and 
selected  signal  types.  The  benchmark  will  specify  the  frequency  bands, 
exclusion  of  frequencies,  and  signal  class/type. 

A  GS  plan  will  be  developed.  It  will  include  a  set  of  data  parameters: 
start  frequency,  stop  frequency,  frequency  step  size,  receiver  bandwidth 
size,  and  signal  class/type.  The  plan  also  includes  exclusion  frequencies 
that  are  specified  to  inhibit  the  reporting  of  signal  activity  at  specified 
frequencies.  The  benchmark  will  step  through  frequencies  defined  in  the  GS 
plan  at  a  rate  of  at  Itfast  SO  frequencies  per  second. 

An  activity  table  will  be  maintained.  The  GS  activity  table  will 
contain  entries  for  the  most  recent  GS  and  manual  direction  finding  (DF) 
that  the  system  performed.  The  parameters  stored  in  the  activity  table 
include  the  time  of  first  and  last  intercept  and  a  location  estimate  for 
each  entry  for  which  OFs  have  been  taken.  The  emitter  location  can  be 
determined  automatically  in  response  to  GS  activity  in  specified  frequency 
bands . 

7. 4. 1.2  Directed  Search  (DS) 

DS  is  the  aucomacic  intercept  of  specific  known  signals.  It  involves 
aucomacic  environment  sampling  at  discrete  frequencies,  and  it  revisits 
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known  emiccers.  The  benchmark  can  specify  a  maximum  of  20  frequencies  for 
aucomaclc  activity  detection. 

The  DS  operation  will  monitor  a  list  of  individual  frequencies 
specified  in  a  DS  plan  and  report  newly  active  signals.  The  DS  plan 
consists  of  the  following:  frequencies  of  Interest,  priorities  associated 
with  each  frequency  (normal,  priority,  monitor),  the  number  of  automatic  DF 
requests  to  be  made  for  each  frequency,  and  s'.mulate  an  operator's  position 
being  alerted  when  an  intercept  is  detected  by  a  DS.  Some  frequencies  will 
be  tagged  for  special  handling  such  as  increased  sampling  rate,  prioritized 
audio  monitoring,  prioritized  audio  recording,  and  geographic  screening. 
The  DS  plan  contains  at  least  12S  entries,  including  20  priority  DS  entries 
and  two  monitor  DS  entries . 

An  activity  table  will  be  maintained  for  each  specified  frequency.  The 
cable  includes  an  activity  counter  for  each  signal  detected  and  the  time  of 
the  last  intercept. 

Each  specified  frequency  will  have  an  associated  priority  assigned  to 
it  that  is  used  to  guarantee  minimum  revisit  intervals.  The  software  will 
determine  the  best  DS  frequency  to  be  examined  while  caking  into  account  the 
relative  priorities  of  the  frequencies.  The  software  steps  through  the 
frequencies  in  the  DS  plan  at  a  minimum  race  of  50  entries  per  second. 
.*lonicor  DS  (highest  priority)  entries  have  a  revisit  time  interval  of  no 
more  chan  0.1  second.  *  Priority  DS  entries  have  a  revisit  time  interval  of 
no  more  chan  0.5  second.  Normal  DS  (lowest  priority)  entries  have  a  revisit 
time  interval  as  determined  by  the  number  of  entries  in  the  DS  plan. 
Automatic  signal  analysis  will  be  specified  for  a  specific  frequency  and  the 
results  screened  according  to  signal  type/modulation. 

7.4.2  Direction  Findlne  (DF) 

The  benchmark  will  make  various  measurements  chat  will  provide  an 
indication  of  the  direction  from  which  a  frequency  signal  originated.  The 
measurement  process  consists  of  several  sequentially  executed  casks  that 
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conclude  wich  the  generation  of  a  Line  of  Position  (LOP) .  DF  processing  can 
be  either  automatically  initiated  or  manually  requested.  The  benchmark  will 
accept  input  data  from  the  DF  related  equipment  and  the  magnetic  field 
converter  via  an  analog- to-digital  converter. 

An  LOP  consists  of  two  pieces  of  data:  a  Line  of  Bearing  (LOB)  and  the 
location  of  the  receiving  measurement  equipment.  An  LOB  is  a  line  drawn 
from  the  measurement  platform  location  at  the  angle  (relative  to  north)  chat 
a  signal  .'.rrived.  When  a  LOB  becomes  referenced  to  a  position  (platform 
location  at  the  time  of  the  bearing),  it  becomes  an  LOP.  The  benchmark  will 
compute  and  format  an  LOB  message  for  a  given  DF  request  within  2. 25  seconds 
of  receipt  of  the  request.  The  benchmark  will  store  the  LOB  data  from  DSs, 
DFs,  and' manual  DFs  in  Che  DF  database  segmented  according  to  frequency. 

The  benchmark  will  schedule  DF  commands  based  on  the  following  DF 
request  priorities:  manual  DF,  monitor  DS,  priority  DS,  normal  DS,  and  CS. 
A  local  queue  of  pending  DF  requests  is  maintained.  The  benchmark  will  also 
allow  voice  and  data  activity  related  to  the  intercepted  frequencies  to  be 
recorded. 

7.4.3  Emitter  Location 

The  benchmark  will  compute  the  location  of  an  emitter  signal.  The 
benchmark  will  use  the  LOPs  to  compute  the  best  estimate  of  the  emitter 
location.  Upon  receipt  of  LOPs  from  a  DF  request  initiated  by  DS  or  by  the 
operator,  the  benchmark  will  attempt  to  associate  the  LOP  set  with  an 
existing  FIX  location  in  a  file.  If  an  association  is  found,  the  LOP  sec  is 
assigned  to  the  corresponding  FIX;  otherwise,  the  benchmark  attempts  to 
generate  an  emitter  location  estimate.  If  a  reasonable  emitter  location 
estimate  cannot  be  determined,  Che  LOP  set  remains  unassigned.  The 
benchmark  will  be  capable  of  computing  and  displaying  a  FIX  from  five  LOPs 
within  300  milliseconds.  Provisions  will  be  made  for  recognizing  multiple 
emitters  sharing  common  frequencies. 


7.4.4  Analysis 


The  benchmark  will  allow  aucomaclc  signal  analysis,  or  it  will  simulate 
an  operator  manually  requesting  a  signal  analysis  at  the  frequency  he  is 
monitoring  with  his  intercept  receiver.  The  following  signal  analysis  data 
results  are  to  be  displayed:  detected  frequency,  signal  type  or  modulation, 
and  audio  classification.  The  signal  classification  section  processes 
Sig-^ial  Classification  Tips  (SCT)  at  a  sustained  rates  of  up  to  20  per  second 
without  losing  data.  Then  the  benchmark  will  compare  the  results  of  signal 
classification  to  the  acceptable  list  of  types  or  modulations  for  the  SCT. 

7.4.5  Reporting 

The  benchmark  will  allow  the  simulation  of  an  operator  viewing  DF  data 
while  generating  a  report.  The  data  specification  parameters  allow  the 
operator  to  view  DF  data  associated  with  a  single  frequency  or  a  frequency 
range,  a  specific  time  span  within  which  the  data  was  collected,  or  a 
specific  geographical  area.  These  data  specification  parameters  are  to  be 
included  in  any  combination. 

The  benchmark  will  generate  reports  semi -automatically  for  transmission 
by  a  reporting  link.  The  software  provides  a  means*  to  facilitate  the 
generation  of  reports  and  messages  via  prompts  and  displayed  templates .  The 
software  formats  the  report  generated  into  a  form  acceptable  for 
transmission  over  the  Reporting  Data  Link  Subsystem  (RDLS). 
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8.0 


The  final  seep  of  this  study  was  to  determine  how  the  benchmarks  should 
be  used  when  selecting  an  RTE.  It  was  determined  that  choosing  an  RTE  is  a 
three-step  process.  The  first  step  is  to  eliminate  all  RTEs  that  cannot 
perform  beyond  a  minimum  required  threshold  in  each  area  critical  to  system 
performance.  The  second  step  is  to  begin  with  the  set  of  RTEs  chat  satisfy 
the  minimum  threshold  requirements  and  select  the  small  set  of  RTEs  that 
performs  best  in  the  areas  critical  to  system  performance.  The  final  step 
is  to  compare  the  costs,  the  vendor  support  provided,  and  any  ocher 
mitigating  circiunstances  for  the  final  selection  of  an  RTE  or  compiler.  The 
first  two  steps  involve  the  use  of  benchmarks. 

The  composite  benchmark  is  to  be  used  to  test  the  minimum  threshold  of 
RTEs .  This  means  the  developer  would  only  have  to  run  one  benchmark  to 
eliminate  all  RTEs  not  suitable  for  his  particular  class  of  system.  Then 
the  ocher  benchmarks  would  be  used  to  test  the  remaining  RTEs  to  see  which 
RTEs  perform  Che  best  in  Che  areas  critical  to  system  performance.  Because 
the  RTE  elements  are  prioritized,  the  critical  areas  and  the  benchmarks  that 
measure  chose  areas  are  known. 

At  this  time  Che  development  of  the  composite  benchmark  is  still  in  the 
preliminary  phase.  Until  the  composite  benchmark  matures,  only  the 
prioritized  list  of  groups  of  benchmarks  can  be  used  to  test  RTEs. 
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9.0  SUMMARY  AND  CONCLUSIONS 


The  objective  of  this  study  was  to  provide  software  developers  with 
guidance  in  the  selection  of  a  compiler  and  its  RTE  to  ensure  all  the  timing 
and  storage  requirements  of  real*time  embedded  systems,  specifically 
COMINT/ELIMT  systems,  are  met. 

To  provide  this  guidance  required  the  Identification  of  Ada  RTE 
features  of  interest  for  real*tlme  systems.  This  involved  two  steps; 
first,  the  Ada  runtime  features  that  are  important  for  real* time  embedded 
systems  were  established;  second,  evaluation  criteria  to  evaluate  the 
features  were  determined.  To  determine  the  important  Ada  runtime  features, 
the  Ada  RTE  elements  were  prioritized.  To  evaluate  the  Ada  runtime 
features,  current  benchmarks  were  prioritized,  and  new  benchmarks  were 
proposed. 

Figure  9*1  provides  the  results  of  each  step  that  was  undertaken  to 
prioritize  benchmarks.  In  the  first  step.  COMINT/ELZNT  systems  were  chosen 
to  be  studied,  and  the  capabilities  common  to  COMIMT/ELINT  systems  were 
identified.  Four  systems  were  chosen  for  in*depth  study  because  they  were 
representative  of  all  COHIMT/ELIMT  systems.  The  second  step  identified  what 
Ada  constructs  would  be  used  to  implement  each  capability.  The  third  step 
identified  which  RTE  element  would  be  used  to  support  the  implementation  of 
each  identified  Ada  construct.  The  forth  step  prioritized  the  Ada  RTE 
elements.  The  prioritization  was  done  by  applying  a  prioritization  matrix 
to  the  RTE  elements.  It  is  recommended  that  when  a  developer  prioritizes 
RTE  elements  and  benchmarks  for  a  particular  class  of  systems,  the  developer 
begin  by  applying  the  prioritization  matrix.  The  prioritization  matrix  was 
originally  developed  for  COMINT/ELINT  systems,  but  It  can  easily  be  modified 
to  be  tised  with  other  classes  of  systems.  The  final  step  prioritized 
benchmarks.  The  benchmarks  mapped  to  a  particular  RTE  element  inherit  the 
priority  of  that  element.  This  study  also  presented  the  idea  of  a  composite 
benchmark,  which  is  one  benchmark  that  will  give  the  software  developer  a 
general  idea  whether  a  particular  RTE  can  perform  the  capabilities  of  a 
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particular  class  of  systems.  A  description  for  a  composite  benchmark  was 
developed  fcr  COMINT/ELINT  systems. 

Benchmarks  are  used  to  identify  RTEs  and  compilers  that  are  best  suited 
for  a  particular  application  domain  by  testing  each  candidate  RTE  to  ensure 
all  system  requirements  can  be  met.  The  results  of  this  study,  specifically 
the  prioritization  matrix,  provide  a  process  that  a  developer  can  use  to 
prioritize  benchmarks.  If  the  critical  elements  of  an  RTE  and  compiler  are 
not  adequately  evaluated,  the  selected  RTE  could  be  crippling  for  a  real* 
time  embedded  system. 
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APPENDIX  A 

REAL-TIME  FUNCTION  DESCRIPTIONS 


This  appendix  contains  the  descriptions  of  the  real-time  functions 
introduced  in  Section  2.0.  The  functions  described  are  those  in  TAfiLE  2-1. 
Also  included  is  the  list  of  functions  from  which  the  real-time  functions 
were  identified. 

function  descriptions 
real-time  characteristic:  monitor 

receiver  -  conversion  of  incoming  electromagnetic  waves  into  digital 
form 

reception  -  action  of  receiving  electromagnetic  signals 
target  detection  •  finding  the  presence  or  existence  of  a  moving  target 
real-time  characteristic:  analyze 

direction  finding  -  process  of  making  measurements  that  indicate  the 

direction  from  which  a  signal  originated 

analysis  -  interpretation  and  classification  of  signals 

location  •  computing  the  location  of  a  signal's  origin 

real-time  characteristic:  respond 

transmitter  -  sending  results  of  analysis  to  designated  parties 

countermeasure  -  after  hostile  missile  detection,  actions  taken  to 
counter  its  original  intent 

antenna  controller  -  guiding  the  antenzia  to  obtain  the  most  efficient 

reception 
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APPENDIX  B 

HOW  ADA  CONSTRUCTS  WERE  IDENTIFIED 


The  following  is  the  discussion  on  how  Ada  constructs  were  identified. 
For  each  system  capability  (intercept,  direction  finding,  analysis,  emitter 
location,  and  reporting)  the  system  operations  that  perform  particular 
capabilities  are  identified.  Then,  the  Ada  constructs  that  perform  a 
particular  operation  are  identified  along  with  an  example  of  how  the 
construct  is  used. 

Due  to  the  amovmt  of  effort  required  for  an  in-depth  analysis  to  obtain 
base  line  Ada  constructs,  one  lEW  COMINT/ELINT  system  was  originally 
studied.  These  base  line  constructs  were  then  validated  by  comparing  them 
to  other  lEW  COMINT/ELINT  systems. 

Because  of  the  similarities  between  direction  finding  and  emitter 
location,  these  two  capabilities  were  combined. 

C.l  Intercept 

Intercept's  major  function  is  to  determine  signal  presence. 

The  critical  constructs  used  for  interception  are  listed  with 
explanations  of  how  it  would  be  used. 

Micro  Constructs 

address  clause  :  used  whenever  an  interrupt  is  used  allocate  needed 
allocation  :  memory  for  incoming  data  to  tell  that  a  message  is 

interrupt  :  waiting  to  be  sent  and  to  indicate  that  a  message  is 

coming  from  another  CPU 

tasks  :  used  to  continually  poll  the  interface  board 

Macro  Constructs 

flags  :  indicate  the  following:  buffer  in  use,  buffer  is  full, 

CPU  is  using  another  resource 

queue  :  when  intercept  is  detected  the  data  is  put  into  a 

queue  going  to  direction  finding 
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C.2  Direction  Finding  and  Eaitcer  Location 
Direction  Finding  (DF) 


The  major  operations  Involved  in  DF  are  scheduling  DF  requests, 
removing  requests  that  have  not  been  processed  in  a  set  amount  of  time,  and 
reporting  the  DF  response  to  the  system  computer. 


The  critical  constructs  used  in  the  DF  were  listed  with  examples  of  how 
they  would  be  used. 


Micro  Constructs 

clock 

delay 

exception 

interrupt 

priority 

Macro  Constructs 

queue 

stacks 

semaphore 


:  for  a  timeout  for  a  specific  period  of  time 
:  used  to  initiate  the  timeout 

:  raised  if  audio  correlation  cannot  be  done  because 
access  is  blocked 

:  interrupt  the  audio  correlator  to  send  message  to 
system  computer 

:  to  establish  priorities  for  direction  finding  requests 


the  DF  output  is  scored  in  queues  how  the  DF  requests 
are  scored  determine  if  audio  correlation  is  free 


The  OF  Algorithm  is  responsible  for  starting  the  data  collection, 
cycling  through  the  data  collected,  accumulating  the  data  in  the  case  of  DF 
requests,  and  calculating  Che  Line  of  Bearing  (LOB). 


The  critical  constructs  used  in  the  OF  Algorithm  will  be  listed  with 
examples  of  how  it  would  be  used. 


Micro  Constructs 

allocation  :  after  data  is  determined  to  be  valid,  memory  is 
allocated  to  score  the  data 
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delay 


exceptions 

Interrupts 


:  used  to  allow  an  analog  device  to  "settle"  before 
taking  baseline  measurement 
:  a  message  is  generated  to  indicate  an  error 
:  used  to  indicate  the  system  has  completed  the  current 
command 


Macro  Constructs 

flag 

queue 


indicate  a  process  has  occurred  messages  sent  are 
queued  so  they  can  be  read  when  ready 


Navigation  System 


The  Navigation  System  is  responsible  for  reading  navigational 
information  from  the  Inertial  Navigation  System  (INS) .  This  is  used  to 
determine  the  emitter  location. 


The  critical  constructs  used  in  the  Navigation  System  were  listed  with 
examples  of  how  they  would  be  used. 


Micro  Constructs 


control  state 

procedure 

assignment 

exception 


decodes  the  commands  and  calls  the  appropriate 
sxibroutine  to  execute  the  command 
calling  the  subroutine  moving  date  problem  with 
updating  the  system 


.Macro  Construct 

event  flag  :  was  identified  to  indicate  that  data  has  been  stored 
in  the  data  buffer  from  the  incoming  serial  port 


C.3  Analysis 


System  Administrators 


The  System  Administrators  serve  as  the  controlling  CPUs.  They  authorize 
the  analysis  CPUs  to  begin  processing  and  control  the  interfaces  becveen 
computers.  The  System  Administrators  control  link  handling,  scheduling, 
directed  and  general  search,  and  list  handling. 
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The  critical  constructs  used  in  the  Administrators  were  listed  with 
examples  of  how  they  would  be  used. 

Micro  Constructs 

For  the  Ground  Digital  Administrator  every  micro  construct  was  identified 
because  it  performs  such  a  large  variety  of  functions  including  scheduling, 
controlling  and  memory  allocation.  Several  examples  of  the  micro  constructs 
are  presented. 

tasks 

clock 
delay 

memory  alloc, 
interrupt 

Macro  Constructs 

mailbox  :  used  to  send  messages  to  the  system  computer  queue 

queue  :  messages  to  be  sent  up  the  link  to  reserve  the 

semaphore  ;  output  link  queue  to  indicate  a  message  has  been 

event  flag  :  received 


The  major  functions  involved  in  SCAR  analysis  include  CPU  system 
initialization,  SCAR  analysis  control,  SCAR  calibration  calculations,  SCAR 
analysis  calculations,  SCAR  discriminant  calculation,  and  SCAR  feature 
vector  calculations. 

The  critical  constructs  used  in  the  SCAR  Analysis  will  be  listed  with 
examples  of  how  they  would  be  used. 

Micro  Constructs 

assignment  :  assign  the  results  of  mathematical  calculations 
interrupt  :  SCAR  CPU  interrupted  to  receive  message  from  the 

administrator 


:  used  for  continuous  looping  to  check  the  response 
queue  for  messages  received 
:  requesting  statxis  Information  at  regular  intervals 
:  reschedules  itself  using  timeouts  allocate  memory  for 
;  received  messages  interrupting  the  system  computer 
:  for  incoming  direction  finding  data 


function  :  calling  mathematical  functions 

Macro  Construct 

mailbox  :  to  Indirectly  pass  messages  queue  SCAR  requests  lock 

queue  :  the  database  from  being  updated 

semaphore 

SCAR  Mathematical  Analysis  Functions 

These  are  routines  that  perform  mathematical  functions  necessary  to 
accomplish  SCAR  analysis. 

Two  micro  constructs  were  Identified  to  perform  the  mathematlca'. 

calculations:  functions  and  the  assignment  statement. 

< 

Macro  Construct 
matrix 

manipulation  :  Involves  dividing,  multiplying,  adding  and  subtracting 
matrices  of  data 

Trigonometry 

functions  :  solving  SINE  and  COSINE  functions 


Analysis  Library  Routines 

The  library  routines  consist  of  functions  needed  by  many  different 
routines.  The  fxinctlons  Include  the  memory  management  routines,  Inter-CFU 
message  passing,  a  random  number  generator,  a  queue  flushing  routine,  the 
accountability  number  generator,  a  frequency  offset  adjuster,  and  directed 
search  entry  address  calculations. 

The  critical  constructs  used  In  the  Analysis  Library  Routines  will  be 
listed  with  examples  of  how  they  would  be  used. 
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Micro  Conscruct;s 

Interrupt 

exception 

Macro  Constructs 

queue 
mailbox 
semaphore 
event  flag 


interrupt  to  receive  a  message  raised  when  message 
is  having  trouble  being  passed 


to  queue  messages  sent  down  the  link  used  to 
indirectly  send  messages  indicate  the  mailbox  is  in 
use  indicate  a  message  has  been  read 


C.4  Reporting 

Uplink  Mul tip  Lexer  Software 


The  'uplink  multiplexer  provides  for  communication.  Memory  space  is 
allocated  for  databases  and  scratch  pad  memory.  I/O  ports  are  initialized, 
and  the  microprocessor  instructions  and  memory  (RAM  and  ROM)  are  verified. 


The  critical  constructs  used  in  the  Uplink  Multiplexer  Software  will  be 
listed  with  exarrples  of  how  they  would  be  used. 


Micro  Constructs 


dynamic  memory 

exception 

interrupt 


create  memory  space  for  the  database  if  memory  cannot 
be  allocated  to  interrupt  the  Receiver  Control  Unit 


Macro  Constructs 

event  flag 
stack 


to  indicate  the  receipt  of  data  how  the  data  is  stored 
in  memory 


Inggrcgi/SB&csim.  PlspUT.Ilg/SJil 


The  IC/SD  processor  is  responsible  for  controlling  the  Integrated 
Processing  Facility  Intercom  System  and  for  providing  the  spectrum  display. 
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The  crlcical  constructs  used  In  the  IC/SD  were  listed  with  examples  of 
how  they  would  be  used. 

Micro  Construct 
tasks 

procedures 

exception 
functions 

Macro  Construct 

event  flag  :  is  used  to  indicate  that  data  has  been  received. 


:  used  in  a  polling  loop  waiting  for  activity 
;  calling  the  appropriate  routine  based  on  what  was 
received  from  the  polling  loop 
:  raised  if  there  is  a  failure  in  passing  data 
:  functions  called  for  testing 
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APPENDIX  C 

ADA  RUNTIME  ENVIRONMENT  DEFINITION 


ARTEWG  defines  an  Ada  RTE  as  Che  set  of  all  capabllicies  provided  by 
three  basic  elemencs;  predefined  subroutines,  abstract  data  structures,  and 
code  sequences . 

Predefined  Subroutines 

The  predefined  subroutines  are  used  by  the  compiler  generated  code  to 
support  features  of  the  Ada  language  chat  the  Ada  implementor  (vendor)  has 
chosen  not  to  directly  represent  in  generated  code.  The  sec  of  predefined 
subroutines  for  a  generated  Ada  program  is  called  the  Runtime  System  for 
chat  particular  program.  These  predefined  subroutines  are  chosen  from  the 
Runtime  Libraries. 

Abstract  Data  Structure 

An  abstract  data  structurq  is  a  grouping  of  related  data  items  in 
memory.  The  items  in  a  data  structure  can  be  processed  individually, 
although  some  operations  may  be  performed  cn  the  structure  as  a  whole. 

Code  Sequences 

Code  sequences  are  commonly  used,  repetitious  lines  of  code  adopted  for 
reliability,  interoperability,  and  suppression  of  unnecessary 
implementation  details.  Code  sequences  are  heavily  affected  by  the  selected 
definitions  of  predefined  types  and  representations  used  for  addressing 
objects.  Related  issues  for  code  sequences  include  whether  there  is  one  or 
multiple  areas  for  package  (i.e.,  global)  data,  what  mechanism  for  uplevel 
referencing  of  objects  is  (e.g.,  static  link  or  display)  and  what  the 
subprogram  call  sequences  and  parameter  passing  mechanism  are  determined  to 
be. 
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The  parcicioning  of  funccionalicles  becveen  code  sequences  and  runclme 
subroutines  presents  another  set  of  Issues  that  oust  be  resolved  In  the 
runtlne  model.  The  decisions  regarding  this  partitioning  are  influenced  by 
the  capabilities  and  limitations  of  the  target  configuration  (e.g.,  how  much 
of  the  tasking  constructs  are  handled  by  inline  code  versus  calls  to 
routines) .  The  best  decision  regarding  allocation  to  either  code  or  runtime 
routines  is  highly  situational  and  must  be  based  upon  the  particular  target 
architecture  and  performance  goals. 

The  runtime  model  resulting  from  the  decisions  described  above  defines 
the  requirements  of  the  design  for  the  RTE  components  listed  in  the 
taxonomy.  The  following  taxonomy  describes  a  list  of  11  functions  chat  can 
be  expected  in  the  runtime  libraries  for  Ada  implementation. 

Dynamic  Memory 

The  dynamic  memory  management  fxxnccion  is  the  part  of  the  RTE  that 
handles  the  allocation  and  deallocation  of  storage  at  runtime.  If  a  request 
for  storage  cannot  be  fulfilled  a  storage  error  will  be  raised. 

Processor  Management 

• 

The  processor  management  function  implements  the  assignment  of  physical 
processors  to  casks  chat  are  "logically  executing."  The  processor 
management  function  is  invoked  by  ocher  components  of  the  RTE  to  block  and 
unblock  Casks.  It  maintains  a  list  of  Cask  priorities  to  determine  which 
cask  should  be  assigned  to  a  processor. 

Interrupt  Management 

The  interrupt  management  function  implements  the  interrupts  for 
asynchronous  events  in  the  underlying  competing  resource.  It  is  not  only 
responsible  for  Initializing  the  interrupt  mechanism  in  the  underlying 
resource,  but  is  also  responsible  for  resecting  the  mechanism  after  the 
interrupt  has  occurred. 
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The  cine  management  function  is  the  portion  of  the  RTE  that  supports 
the  predefined  package,  Calender.  This  includes  the  support  for  the  clock 
function  and  delay  statement. 

Exception  Management 

The  exception  management  function  implements  the  Ada  semantics  for 
exception  handling.  It  determines  whether  there  is  a  matching  handler  for 
Che  exception.  If  one  is  present  it  transfers  control  to  Che  handler.  If  no 
matching^  handler  is  available  it  invokes  the  cask  termination  function  Co 
terminate  the  cask  at  hand  or  to  terminate  the  main  program.  Both 
predefined  and  user<defined  Ada  exceptions  may  be  raised. 

Rendezvous  Management 

The  rendezvous  management  function  implements  the  semantics  of  the  Ada 
rendezvous  model.  It  monitors  which  casks  are  blocked  because  they  are 
waiting  to  rendezvous  with  ocher  casks;  and  it  determines  the  exact 
circumstances  of  these  wait  states. 

Task  Activation 

The  Ada  Language  allows  the  dynamic  creation  of  Casks.  The  cask 
activation  fxmccion  is  invoked  by  the  creator  of  a  new  task  in  order  to 
start  the  new  casks  activation. 

Task  Termination 

The  cask  termination  function  contains  the  sec  of  rules  for  the 
completion,  termination  and  abortion  of  casks. 
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This  part  of  the  Ada  runtime  environment  supports  input  and  output, 
including  all  of  the . functions  that  support  predefined  packages  from  Chapter 
14  of  the  Ada  Reference  Hanual. 

Commonly  Called  Sequences 

This  category  is  a  "catch  all."  It  includes  runtime  routines  in  the 
classical  sense,  commonly  called  sequences  of  code. 

Target  Housekeeoine  Functions 

Target  Housekeeping  functions  are  the  parts  of  the  Ada  RTE  that  are 
responsible  for  starting  up  and  terminating  the  execution  environment  of  an 
Ada  program. 


APPENDIX  D 

VEICHTING  OF  ECS  FEATURES 


I/O  Control 

COHINT/ELINT  systems  have  strong  dependence  on  input  end  output.  The 
major  aspect  of  COMINT/EUNT  systems  is  the  interception  and  monitoring  of 
either  electronic  or  comnunications  signals.  The  systems  need  to  enable  and 
disable  devices,  handle  device  interrupts,  and  be  able  to  move  data  to  and 
from  data  registers.  I/O  control  is  the  highest  weighted  criteria  in  the 
decision  matrix  because  of  the  nximber  of  requirements  mapped  to  it  and 
because  the  COMINT/ELINT  Systems  most  important  capability.  Intercept, 
heavily  involves  I/O.  Intercept  is  the  most  important  capability  since  if 
no  signal's  are  found  and  intercepted,  the  system  is  useless. 

Another  major  part  of  COMINT/ELINT  I/O  is  the  communications  between 
CPUs.  All  COMINT/ELINT  Systems  are  comprised  of  multiple  CPUs  ranging  from 
microprocessor  chips  to  large  main  frames  (Perkin  Elmer) .  There  is 
extensive  I/O  between  the  CPU's.  For  example,  consider  the  following: 
Three  microprocessors  located  on  an  airplane  interact  to  perform 
interceptions,  direction  finding,  and  signal  analysis.  Then  the  intercepted 
signal  and  the  analysis  is  sent  to  three  microprocessors  on  the  ground 
through  one  microprocessor  dedicated  for  multiplex  communication.  On  the 
ground  the  signal  is  further  analyzed  for  location  and  characteristics. 
Then  the  signal  is  sent  to  a  main  frame  computer  for  continued  analysis  by 
an  operator  and  for  generation  of  reports.  For  reporting  the  analyzed  data 
to  commands  in  the  field,  the  information  is  sent  back  to  the  airplane  for 
dissemination.  This  simple  explanation  of  a  complex  process  of  I/O  provides 
an  idea  of  how  extensively  I/O  between  CPUs  is  used  within  COMINT/ELINT 
Systems . 

Timing  Control 

Strict  timing  demands  must  be  satisfied  for  COMINT/ELINT  systems.  The 
software  requirements  specify  exactly  what  timing  requirements  must  be  met. 
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For  example,  in  Trailblazer  B  the  software  must  be  capable  of  computing  and 
displaying  a  FIX  (location)  from  3  lines  of  bearing  within  300  milliseconds. 
If  this  and  ocher  timing  constraints  are  not  met,  valuable  data  is  lost  or 
not  analyzed.  This  valuable  data  cannot  be  recovered,  but  the  system  does 
not  completely  fail  if  a  timing  requirement  is  not  met.  Because  of  this, 
the  timing  requirements  are  strict  but  not  critical.  The  timing  control 
feature  is  Che  second  highest  feature. 

Concurrent  Control 

One  requirement  for  real*cime  embedded  computer  system  is  parallelism. 
COMINT/ELINT  systems  depend  heavily  on  concurrent  control.  Concurrent 
processing  must  be  used  to  meet  the  strict  timing  requirements  needed  to 
intercept,  analyze,  and  disseminate  COMINT/ELINT  signals.  Concurrent 
processing  dramatically  increases  the  speed  at  which  data  can  be 
intercepted,  analyzed  and  disseminated.  Concurrent  control  allows  for  two 
capabilities,  i.e.,  intercept  and  DF,  to  be  performed  concurrently.  For 
example,  one  task  can  be  dedicated  to  the  interception  and  monitoring  of 
signals  on  a  particular  frequency.  This  cask  will  continually  monitor  the 
frequency  without  interruption,  while  another  cask  can  be  dedicated  to 
determine  the  direction  from  which  the  signal  originated.  If  there  were  no 
concurrent  processing  the  monitoring  of  a  signal  would  have  to  be 
interrupted  for  a  period  of  time  while  the  direction  was  being  determined. 
With  this,  valuable  <.uLaiui.icacioTi  or  electronic  data  could  be  lost.  Another 
example  is  one  cask  can  be  dynamically  created  to  monitor  each  frequency 
from  which  a  signal  has  been  intercepted.  This  allows  for  the  monitoring  of 
multiple  frequencies.  When  a  frequency  no  longer  has  any  activity,  a  task 
can  be  terminated. 

Because  concurrent  control  must  be  used  to  meet  the  strict  timing 
requirements,  the  weighting  of  these  to  features  are  the  same. 
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COMINT/ELINT  systems  use  low-level  Interfaces  to  communicate  with  hard 
wire  devices  (receiver  control  units)  which  perform  the  actual  interception 
of  the  signals.  This  involves  the  conversion  of  the  data  signal  from  analog 
to  digital.  To  store  incoming  data,  efficient  data  representation  in  terms 
of  the  xuiderlying  computer  architecture  is  needed.  These  involve  the  use  of 
tightly  packed  data  structures,  dedicated  memory  locations,  and  special- 
purpose  registers  [Veiderman  1987a] . 

The  highest  weighted  feature  is  I/O  control.  All  the  data  that  is 
intercepted  must  be  stored  in  an  efficient  manner.  This  involves  strict 
control  of  how  and  where  the  data  is  to  be  stored.  This  involves 
determining  the  amount  of  memory  to  be  allocated  for  a  particular  data 
object  and  also  the  amount  of  memory  to  be  allocated  for  a  dynamically 
created  cask. 

Internal  Representation  is  weighted  higher  then  error  handling  and 
numeric  computations,  because  COMINT/ELINT  systems  rely  heavily  on  I/O 
control. 

Error  Handling 

Real-time  embedded  software  must  be  reliable,  where  reliability  is 
typically  measured  in  terms  of  the  system's  availability,  the  mean  time 
between  failures,  the  meantime  to  repair  and  the  frequency  of  failure.  The 
normal  approach  developers  have  taken  in  order  to  meet  reliability 
requirements  is  to  design  the  Real-time  system  in  such  a  manner  that  it  can 
recover  from  its  errors.  Real-time  software  must  be  able  to  both  detect  and 
subsequently  recover  from  errors  [Veiderman  1987A] . 


Most  COMINT/ELINT  system  have  built  in  test  equipment  (BITE) .  BITE 
tests  all  the  five  capabilities  each  time  before  a  system  is  activated  for 
actual  use.  BITE  can  also  be  activated  at  any  time  during  actual  system 


operation.  Most  errors  should  be  detected  before  the  system  is  in  actual 
use  so  error  handling  is  still  important  but  not  critical. 


COHINT/ELINT  systems  rely  on  complex  mathematical  algorithms  for 
analyzing,  direction  finding,  and  determining  emitter  location.  The  major 
importance  is  the  time  it  takes  to  perform  the  algorithms  and  also  the 
representation  and  implementation  of  the  physical  quantities  (float  point  or 
fixed  point) .  Numeric  computations  and  error  handling  are  important 
features,  but  for  COMINT/ELINT  systems  they  are  the  lowest  weighted 
features . 
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APPENDIX  E 

RATING  EACH  RTE  ELEMENT 


The  following  is  e  discussion  of  each  RTE  element  and  its  effect  on  the 
performance  of  each  ECS  feature.  This  section  is  divided  by  ECS  feature  and 
within  each  feature  is  a  listing  of  each  RTE  element,  its  rating,  and  a  brief 
discussion  of  how  a  particular  rate  was  chosen. 
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Concurrent  Control 


RTE  Element 

Rating 

aigw.sgi<?.B 

Memory  Management 

9 

Memory  management  is  intrinsic  because  of  the 
need  to  store  data  during  context  switching. 
Also,  there  may  be  a  need  to  dynamically 
create  tasks  in  real-time  embedded  systems. 

Processor  Management 

9 

Processor  management  is  intrinsic  because  it 
implements  the  assignment  of  physical 
processors  to  cask  that  are  logically 
executing  when  running  parallel  operations. 

Interrupt  Management 

5 

Interrupt  management  is  a  supportive  because 
if  the  address  clause  for  cask  entries  are 
implemented,  the  interrupt  management  element 
utilizes  Che  rendezvous  management  element  to 
realize  interrupt  rendezvous  [ARTWG87].  It  is 
not  intrinsic  because  interrupt  rendezvous  do 
not  always  have  to  be  used. 

Time  Management 

9 

It  is  intrinsic  because  of  the  extensive  use 
of  time  entry  calls  (delay  statement)  in  real¬ 
time  embedded  systems. 

Exception  Management 

5 

A  fault  can  be  raised  anytime  during  system 
execution.  It  is  highly  recommended  but  not 
mandatory  that  some  type  of  exception 
management  be  used. 

Rendezvous  Management 

9 

The  Rendezvoxis  of  Casks  is  intrinsic  for 
concurrent  control*'. 

Task  Activation 

9 

Task  Activation  is  intrinsic  for  concurrent 
control . 

Task  Termination 

9 

Task  Termination  is  intrinsic  for  concurrent 
control. 

I/O  Management 

5 

I/O  Management  is  supportive  because  casks 
can,  but  do  not  have  to,  be  used  during  input 
and  output. 

Commonly  Called  Code 
Sequences  (CCCS) 

1 

CCCS  plays  a  minor  role  in  concurrent  control. 

Target  Housekeeping 

1 

Target  Housekeeping  plays  a  minor  role  in 
concturrcnc  control. 
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RTE  Elements 
Memory  Management 

Processor  Management 

Interrupt  Management 

Time  Management 

Exception  Management 

Rendezvous  Management 

Task  Termination 

Task  Activation 

I/O  Management 

CCCS 

Target  Housekeeping 


Racing 

5 


9 


5 


9 


5 


9 


5 


5 


9 


1 

5 


Time  Control 
Discussion 

The  time  it  takes  to  dynamically  create 
variables  or  tasks  may  or  may  not  be  time 
critical. 

The  time  in  which  a  task  is  given  sole  use  of 
the  processor  (in  a  uniprocessor  system)  is 
critical . 

Interrupts  from  hardware  timers  may  need  to  be 
passed  on  to  the  time  management  element  to 
determine  the  length  of  the  interrupt.  This 
time  period  may  or  may  not  be  time  critical. 

Time  Management  is  intrinsic  because  of  the 
use  of  the  package  calendar  and  the  delay 
statement  in  meeting  timing  constraints. 

A  fault  can  be  raised  anytime  during  system 
execution.  It  is  highly  recommended,  but  not 
mandatory,  that  some  type  of  exception 
management  be  used. 

Time  overhead  to  perform  a  rendezvous  must  be 
considered  when  trying  to  meet  strict  timing 
constraints . 

The  time  it  takes  to  terminate  a  task  may  or 
may  not  be  critical.  Task  termination  plays  a 
role  in  time  control,  but  it  is  not  inherent. 

The  time  it  takes  to  activate  a  task  may  or 
may  not  be  critical.  Task  activation  plays  a 
role  in  time  control,  but  it  is  not  inherent. 

I/O  in  real' time  embedded  systems  is  subject 
to  strict  timing  constraints.  I/O  management 
is  intrinsic  to  time  control. 

CCCS  plays  a  minor  role  in  time  control. 

The  time  it  takes  to  start  up  and  terminate  a 
computer  system  may  be  important  for  some 
real'time  embedded  systems. 
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I/O  Control 


RTE  Elements 
Memory  Management 


Processor  Management  5 


Interrupt  Management  9 


Exception  Management  5 


Rendezvous  Management  S 


Task  Activation  1 

Task  Termination  1 
I/O  Management  9 
CCCS  1 


Discussion 

During  the  input  or  output  of  data,  memory  is 
always  being  allocated  or  deallocated. 

Ada  tasks  can  be  used  to  monitor  asynchronous 
input.  If  they  are,  the  processor  maiiagemenc 
element  will  play  a  role. 

Interrupt  management  is  intrinsic  because  low- 
level  asynchronoxis  I/O  operations  to  and  from 
hardware  devices  are  interrupt  driven. 

A  fault  can  be  raised  anytime  during  system 
execution.  It  is  highly  recommended  but  not 
mandatory  that  some  type  of  exception 
management  be  used. 

Ada  tasks  can  be  used  to  monitor  asynchronous 
input.  If  they  are,  the  rendezvous  management 
element  will  play  a  role. 

Task  activation  plays  a  minor  role  in  I/O 
management . 

Task  Termination  plays  a  minor  role  for  I/O 
management. 

The  I/O  Management  element  is  intrinsic  for 
I/O  control. 

CCCS  plays  a  minor  role  in  I/O  management. 


Target  Housekeeping 


1 


Target  Housekeeping  plays  a  minor  role  in  I/O 
control . 


Error  Handling 


Memory  Management 


Processor  Management 


Interrupt  Management 


Time  Management 


A  fault  can  be  raised  anytime  during  system 
execution.  It  is  highly  recommended,  but  not 
mandatory,  that  some  type  of  exception 
management  be  used. 

A  fault  can  be  raised  anytime  during  system 
execution.  It  is  highly  recommended,  but  not 
mandatory,  that  some  type  of  exception 
management  be  used. 

A  fault  can  be  raised  anytime  during  system 
execution.  It  is  highly  recommended,  but  not 
mandatory,  that  some  type  of  exception 
management  be  used. 

A  fault  can  be  raised  anytime  during  system 
execution.  It  is  highly  recommended,  but  not 
mandatory,  that  some  t^^e  of  exception 
management  be  used. 


Exception  Management  9  Exception  management  is  intrinsic  to  the 

performance  of  error  handling  in  a  embedded 
computer  system. 

Rendezvous  Management  5  A  fault  can  be  raised  anytime  during  system 

execution.  It  is  highly  recommended,  but  not 
mandatory,  that  some  type  of  exception 

management  be  used. 

Task  Activation  5  A  fault  can  be  raised  anytime  during  system 

execution.  It  is  highly  recommended,  but  not 
mandatory,  that  some  type  of  exception 

management  be  used. 

Task  Termination  5  A  fault  can  be  raised  anytime  during  system 

execution.  It  is  highly  recommended,  but  not 
mandatory,  that  some  type  of  exception 

management  be  used. 

I/O  Management  S  A  fault  can  be  raised  anytime  during  system 

execution.  It  is  highly  recommended,  but  not 
mandatory.  that  some  type  of  exception 

management  be  used. 
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cccs 


5 


A  fault  can  be  raised  anytime  during  system 
execution.  It  is  highly  recommended,  but  not 
mandatory,  that  some  type  of  exception 
management  be  used. 

Target  Housekeeping  5  A  fault  can  be  raised  anytime  during  system 

execution.  It  is  highly  recommended,  but  not 
mandatory,  that  some  type  of  exception 
management  be  used. 
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Memory  Hanagemenc 


Processor  Hanagemenc 


Interrupt  Management 


Time  Management 


Exception  Management 


Rendezvous  Management 


Task  Activation 


Task  Termination 


I/O  Management 


Target  Housekeeping 


Numeric  Computations 

Rating  Discussion 

1  Memory  management  plays  a  minor  role  in 

numeric  cootpucations . 

1  Processor  management  plays  a  minor  little  role 

in  numeric  computations. 

1  Interrupt  management  plays  a  minor  role  in 

numeric  computations. 

1  Time  management  plays  a  minor  role  in  numeric 

computations . 

5  A  fault  can  be  raised  anytime  during  system 

execution.  It  is  highly  recommended,  but  not 
mandatory.  that  some  type  of  exception 
management  be  used. 

1  Rendezvous  management  plays  a  minor  role  in 

nxxBerie  computations. 

1  Task  activation  plays  a  minor  role  in  numeric 

computations . 

1  Task  Termination  plays  a  minor  role  in  numeric 

computations . 

1  I/O  Management  plays  a  minor  role  in  numeric 

computations.  _ 

9  CCCS  is  intrinsic,  because  it  includes  runtime 

routine  for  multi-word  arithmetic  functions. 

5  Target  housekeeping  plays  a  role  in  numeric 

computations,  because  initial  values  of 
variable  can  be  done  during  system 
initialization. 
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Internal  Representation 


RIE.EIgflimg 
Menory  Management 

Processor  Management 
Interrupt  Management 
Time  Management 
Error  Management 

Rendezvovis  Management 
Task  Activation 

Task  Termination 

I/O  Management 

CCCS 

Target  Housekeeping 


B,a£iQg  Discussion 


9 


I 

1 

I 

5 


1 

1 

I 

5 


5 


9 


Embedded  computer  systems  must  have  strong 
control  over  dynamic  storage  and  how  variables 
and  tasks  are  represented  in  storage. 

Processor  management  plays  a  minor  role  in 
internal  representation 

Interrupt  management  plays  a  minor  role  in 
internal  representation. 

Time  management  plays  a  minor  role  in  internal 
representation . 

A  fault  can  be  raised  anytime  during  system 
execution.  It  is  highly  recommended,  but  not 
mandatory,  that  some  type  of  exception 
management  be  used. 

Rendezvous  management  plays  a  minor  role  in 
internal  representation. 

Task  activation  plays  a  minor  role  in  internal 
representation . 

Task  termination  plays  a  minor  role  in 
internal  representation. 

I/O  management  plays  a  role  in  internal 
representation,  because  hov  data  is  to  be 
stored  after  it  is  input  may  be  important  in  a 
real-time  system  in  which  storage  is  at  a 
premium. 

CCCS  plays  a  role  in  internal  representation, 
because  hov  the  interim  results  of  multi-word 
arithmetic  problems  are  stored  are  important 
in  a  real-time  embedded  system  in  which 
storage  is  at  a  premium. 

Target  Housekeeping  is  intrinsic  for  internal 
representation,  because  the  declaration  of 
variables  (which  determines  hov  they  are  to  be 
represented  in  storage)  is  done  during  system 
initialization. 
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APPENDIX  F 

PRIORITIZED  BENCHMARK  LIST 


The  following  is  Che  list  of  benchaacks  grouped  by  the  RTE  element  chey 
measure .  The  order  of  the  groups  is  a  result  of  prioritizing  the  RTE  elements . 
The  benchmarks  that  measure  the  highest  priority  element  are  in  the  first  group 
and  the  benchmarks  that  measvire  the  second  highest  priority  element  are  in  the 
second  group,  and  so  on. 

Each  benchmark  has  a  corresponding  niimber.  This  number  was  taken  directly 
from  a  benchmark's  source  which  allows  the  reader  to  return  to  the  source  and 
obtain  more  information  about  a  particular  benchmark.  Those  benchmarks  with 
identifidation  numbers  consisting  of  all  digits  and  decimal  points  are  from  [GOEL 
1988].  The  others,  whose  identification  numbers  start  with  a  letter  and  contain 
several  zeros  and  end  with  a  nonzero  digit,  are  from  [PIVC  1988]. 
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MEMORY  MANAGEMENT 
MEMORY 


4. 1.1.1 

4. 1.1. 7 


4.3.1 

4.3.2 

4.3.3 


4. 1.1. 2 


DOOOOOl 

DOOOOQ2 

D000003 

D000004 


Oecermine  if  cask  space  is  deallocated  on  return  from  a  procedure 
(when  a  Cask  that  has  been  allocated  via  the  new  operator  when 
that  procedure  terminates). 

The  attributes  SIZE  and  ST0RAGE_,SIZE  provide  information  about 
storage  assignments  for  cask  objects  and  types.  These  attributes 
can  also  be  used  to  specify  an  exact  size  (amount  of  storage)  to 
be  associated  with  a  cask  type.  It  is  important  to  know  how  much 
storage  a  task  object  is  allocated.  Also  how  is  nincime  storage 
allocated  for  casks?  heap?  stack? 

Determine  STORAGE^ERROR  threshold. 

Determine  if  Garbage  collection  is  performed  on  Che  fly. 

Determine  if  Garbage  collection  is  performed  on  scope  exit.  In 
cnis  test  an  access  type  Co  an  array  of  10000  integers  is  declared 
in  a  procedure  called  from  the  main  program.  This  subprogram  is 
called  repeatedly  and  if  storage  is  not  being  automatically 
deallocated  upon  scope  exit,  STORAGE.ERROR  will  again  be  raised. 
If  garbage  collection  is  implicitly  called,  no  ST0RAGE_ERR0R 
exception  will  be  raised. 

Determine  if  Casks  chat  are  allocated  dynamically  by  the  execution 
of  a  allocator  do  not  have  their  space  reclaimed  upon  termination 
when  access  type  is  declared  in  a  library  unit  or  outermost  scope. 


TIME 


Dynamic  array  allocation,  use  and  deallocation  time.  Dynamic 
array  elaboration,  1000  integers  in  a  procedure,  get  space  and 
free  it  in  the  procedure  on  each  call. 


Dynamic  array  elaboration  and  initialization  time  allocation, 
initialization,  use  and  deallocation  1000  integers  initialized  by 
others  eqvusi  to  1. 

Dynamic  record  allocation,  and  deallocation  time  elaborating, 
allocating  and  deallocating  record  containing  a  dynamic  array  of 
1000  integers. 

Dynamic  record  allocation,  and  deallocation  time  elaborating, 
initializing  by  (DYNAMIC^SIZE,  (others  equal  to  1))  record 
containing  a  dynamic  array  of  1000  integers. 


F-Z 


3. 5. 4.1 

3. 5.4.2 

3. 5.4.3 

3. 5. 4. 4 

3. 5. 4. 5 


Measure  time  for  allocating  storage  knovm  at  compile  time. 

Measure  Time  for  Allocating  Variable  Amount  of  Storage 
Memory  Allocation  via  the  Hew  Allocator 

Memory  Allocation  via  the  New  Allocator  when  there  are  active 
tasks  in  the  system 

Determine  the  effect  on  time  required  for  d^’namic  memory 
allocation  tdien  memory  is  continuoxisly  allocated  without  being 
freed. 


IF-AND-HOW 


4.3.4 


Determine  if  Unchecked  Deallocation  is  implemented. 
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TIME  MANAGEMENT 


3.4.2 

3. 9. 1.1 

3.10.1.1 

3. 9. 1.2 


TIME 


Measure  the  actual  delay  tiise  vs  the  specified  delay  time. 

Measure  CLOCK  function  overhead. 

Measure  the  overhead  associated  with  a  call  to  and  return  from  the 
and  *•”  functions  provided  in  the  package  CALENDAR. 


IF-AND-HOW 

Measure  CLOCK  resolution. 
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I/O  management 


3.13.1.1 


IF-AND-HOU 


Determine  if  true  asynchronous  1/0  is  implemented.  Benchmark 
Design:  In  the  main  procedure,  three  separate  tasks  are 
activated.  Task  1  is  the  highest  priority  task,  task  2  is  medium 
priority,  and  task  3  is  a  low  priority  task.  Task  1  makes  a 
request  from  an  I/O  device,  then  task  2  makes  a  request  to  the 
same  I/O  device.  Both  task  1  and  task  2  should  be  suspended  and 
task  3  should  be  executing  at  this  point. 
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PROCESSOR  MANAGEMENT 


TIME 


4. 1.3. 3 


Determine  if  a  low  priority  task  activation  could  result  in  a  very 
long  suspension  of  a  high  priority  task. 


IF-AND-HOW 


3.4.1 


4.2.1 

4.2.2 

4. 1.3.1 


Determine  if  user  tasks  are  preemptive.  Does  a  completed  delay 
interrupt  the  currently  executing  task  to  allow  the  schedule  to 
select  the  highest  priority  tasks. 

Determine  the  method  of  sharing  the  processor  within  each  priority 
to  prevent  starvation  of  any  single  task. 

Does  delay  0.0  simply  return  control  to  the  calling  task  or  causes 
scheduling  of  another  task. 

Determine  priority  of  tasks  (and  of  the  main  program)  that  have  no 
defined  priority. 
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RENDEZVOUS  MANAGEMENT 


3. 3. 2. 2 
3. 3.2.2 

3. 3. 2. 2 

3. 3. 2. 2 

3. 3. 2. 2 

3. 3. 2. 2 

3. 3. 2. 2 

3. 3. 2. 2 

3. 3. 2. 2 
3. 3. 2. 2 

3. 3. 2. 2, 
TOOOOOl 


TIME 


.1  Measure  doe  for  simple  rendezvous 

.2  Measure  time  for  simple  rendezvous.  More  Chan  one  entry  is  called 

CO  measure  rendezvous  time.  These  entries  can  all  be  in  a  single 
cask  or  single  entries  in  multiple  casks. 

.3  Measure  the  affect  on  the  time  required  for  a  simple  rendezvous, 

where  a  procedure  in  the  main  program  calls  an  entry  in  another 

task  with  no  parameters  as  the  number  of  accept  alternatives  in 
the  selective  wait  Increases.  This  benchmark  is  executed  with  the 
following  scenarios; 

.4  Measure  the  affect  of  guards  (on  accept  statements)  on  rendezvous 

time,  where  the  main  program  calls  an  entry  in  another  cask  (wlch 
no  parameters)  as  the  number  of  accept  alternatives  in  the  select 
statement  increases.  This  benchurk  is  executed  with  the 
following  scenarios: 

.5  Measure  the  time  required  for  a  complex  rendezvous,  where  a 

procedure  In  the  main  program  calls  an  entry  in  another  task  with 
different  type,  number  and  mode  of  the  parameter?. 

.6  Measure  the  affect  on  time  required  for  a  complex  rendezvous, 

where  the  main  program  calls  an  entry  in  another  task  with 
different  type,  number  and  mode  of  the  parameters  as  the  number  of 
accept  alternatives  in  the  select  statement  increase.  The 
benchmark  is  executed  with  the  following  scenarios: 

.7  Measure  the  cost  of  using  the  terminate  option  in  a  select 

statement. 

.8  Measure  the  overhead  due  to  a  conditional  entry  call  when  a)  the 

rendezvous  is  completed  and  b)  the  rendezvous  is  not  completed 

.9  Measure  overhead  due  to  a  timed  entry  call; 

.9  Measure  the  affect  on  time  required  for  a  complex  rendezvous, 

where  a  procedure  in  the  main  program  calls  an  entry  as  the  nximber 
of  activated  tasks  in  the  system  increases. 

10  Measure  rendezvous  latency. 

Minimum  rendezvous,  entry  call  and  return  time.  1  task,  1  entry, 
task  inside  procedure,  no  select. 
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T000002 

T000003 

T000004 

T000005 

T000006 

4. 1.2.1 

4. 1.2. 2 

4. 1.2. 3 

4. 1.2. 4 


Tasking  entry  call  and  return  tloe.  1  cask  active,  1  entry,  cask 
in  a  package,  no  select. 

Tasking  entry  call  and  return  time.  2  casks  active,  1  entry  per 
cask,  cask  in  a  package,  no  select. 

Tasking  entry  call  and  return  tine.  1  cask  active,  2  entries, 
cask  in  a  package,  using  select  statenent. 

Tasking  entry  call  and  return  time  10  casks  active,  1  entry  per 
cask,  cask  in  a  package,  no  select. 

Tasking  entry  call  and  return  time.  1  Cask  with  10  entries,  cask 
in  a  package,  one  select.  Compare  with  T000003. 


IF-AND-HOW 


Determine  algorithm  used  when  choosing  among  branches  of  a 
selective  wait  statement.  The  implementation  may  make  a)  a  random 
selection,  b)  select  entry  call  that  arrived  first,  c)  select  the 
first  eligible  accept  alternative  or  d)  select  the  cask  with  the 
highest  priority  making  the  entry  cal.. 

Determine  the  order  of  evaluation  for  guard  conditions  in  a 
selective  wait 

Determine  method  used  Co  select  from  delay  alternatives  of  the 
same  delay  in  a  selective  wait. 

Vhen  are  the  expressions  of  an  open  delay  alternative  or  the  entr^r 
family  index  in  an  open  accept  alternative  evaluated. 


4. 1.3. 2 


Determine  priority  of  a  rendezvous  between  two  Casks  without 
explicit  priorities. 


EXCEPTION  MANAGEMENT 


3. 6. 3.1 

3. 6. 3. 2 

3. 6. 3. 3 

3. 6. 3. 4 

3. 6. 3. 5 

3. 6. 3. 6.1 

3. 6. 3. 6. 2 

EOOOOOl 

E000002 

E000003 

4. 1.1. 5 


TIME 


Measure  a}  claing  overhead  due  co  exceptions  and  b)  exception 

response  tiae  when  exception  is  handled  in  the  block  statement. 

Measure  a)  ciaing  overhead  due  to  exceptions  and  b)  exception 

response  time  when  exception  handled  in  the  block  statement  while 
additional  casks  are  present  in  the  system. 

Measure  Exception  handling  time  when  exception  is  raised  and 

propagated  one  level  below  where  it  is  handled. 

Measure  Exception  handling  time  when  exception  is  raised  and 

propagated  3  levels  below  where  it  is  handled. 

Measure  Exception  handling  time  when  exception  is  raised  and 

propagated  4  levels  below  where  it  is  handled. 

Measure  time  to  propagate  TASKING_ERROR  exception  in  the  calling 
as  well  the  called  cask.  ~ 

Measure  time  to  propagate  and  handle  an  exception  when  a  child 
cask  has  an  error  during  its  elaboration. 

Time  co  raise  and  handle  an  exception.  Exception  defined  locally 
and  handled  locally. 

Time  co  raise  and  handle  an  exception.  Exception  is  in  a 
procedure  in  a  package. 

Time  to  raise  and  handle  an  exception.  Exception  is  in  a  package, 
4  deep. 


IF-AND-HOW 


If  Che  allocation  of  a  cask  object  raises  the  exception 
STOBAGE^ERROR,  when  is  the  exception  raised?  The  LRM  does  not 
define  when  STORAGE_ERROR  nnisc  be  raised  should  a  cask  object 
exceed  the  storage  allocation  of  its  creator  or  master.  The 
exception  must  b«  no  later  chan  cask  activation:  however  an 
implementation  may  choose  to  raise  it  earlier. 

Does  an  implementation  raise  NUMERIC_ERROR  on  an  intermediate 
operation  when  the  larger  expression  can  be  correctly  computed? 
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INTERRUPT  MANAGEMENT 


TIME 


3. 8. 3.1  Measure  Interrupt  Response  Time 


IF-AND-HOU 


^.5.1.1  Oetemine  if  an  interrupt  entry  call  is  implemented  as  a  normal 

Ada  entry  call,  a  timed  entry  call,  or  a  conditional  entry  call. 

4. 5. 1.2  Determine  if  an  interrupt  is  lost  when  an  interrupt  is  being 

handled  and  another  interrupt  is  received  from  the  same  device 

4. 5. 1.4  .  Determine  if  an  interrupt  entry  call  invokes  any  scheduling 

decisions 

4. 3. 1.5  Determine  if  an  accept  statement  executes  at  the  priority  of  the 
hardware  interrupt,  and  if  priority  is  reduced  once  a 
synchronization  point  is  reached  following  the  completion  of 
accept  statement. 

4. 3. 1.6  Determine  if  entries  can  be  called  from  application  code. 
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TASK  ACTIVATION 


3. 3. 2. 1.1 

3. 3. 2. 1.2 

3. 3. 2. 1.3 

3. 3. 2. 1.4 

3. 3. 2. 1.5 

COOOOOl 

C000002 

C000003  ’ 

4. 1.1. 3 

4. 1.1. 4 

41.1.5 


TASK  TERMINATION 

TIME 


Measure  task  activation  and  termination  time  (without  the  new 
operator) 

Measure  activation/termination  time  for  a)  an  array  of  casks  and 
b)  task  object  declared  as  part  of  a  record 

Measure  the  time  to  activate  a  cask  created  via  the  new  allocator 

Measure  the  time  to  activate  and  terminate  a  task  object  declared 
in  Che  declarative  part  of  a  block  as  the  number  of  existing 
active  Casks  keeps  on  increasing 

Measure  the  time  to  activate  and  terminate  a  cask  created  via  the 
new  allocator  in  a  block  as  the  number  of  existing  active  casks 
keeps  on  increasing 

Task  create  and  terminate  measurement  with  one  task,  no  entries, 
when  task  is  in  a  procedure  using  a  task  type  in  a  package,  no 
select,  no  loop. 

Task  create  and  terminate  measurement,  with  one  cask,  no  entries, 
when  cask  is  in  a  procedure  Cask  defined  and  used  in  a  procedure, 
no  select,  no  loop. 

Task  create  and  terminate  measurement,  with  one  Cask,  no  entries 
when  task  is  in  declare  block  of  main  procedure,  cask  is  in  the 
loop . 

IF-AND-HOU 


Determine  the  order  of  elaboration  when  several  casks  are 
activated  in  parallel.  When  several  casks  are  activated  in 
parallel,  the  order  of  their  elaboration  may  affect  program 
execution. 

Determine  if  a  cask  will  continue  execution  following  its 
activation  but  prior  to  the  C'>mpIecion  of  activation  of  ocher 
casks  declared  in  the  same  declarative  part.  (See  the  Real-time 
Benchmarks  paper  for  details) 

What  happens  to  casks  declared  in  a  library  package  when  the  main 
program  terminates?  For  some  real-time  embedded  applications,  it 
is  desirable  chat  such  casks  do  not  terminate. 
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4.1.1.10.1  Determine  order  of  evaluation  of  tasks  named  in  an  abort 
statement.  An  abort  statement  provides  a  convenient  way  to 
terminate  a  task  hierarchy.  When  a  task,  Tl,  aborts  a  task,  T2, 
the  result  T2 ' COMPLETED  Is  true  when  evaluated  by  Tl.  Other  casks 
may  not  immediately  detect  that  T2' COMPLETED  is  true.  In  real¬ 
time  embedded  systems ,  tasks  may  have  Co  be  aborted  in  a  certain 
sequence.  The  semantics  of  the  abort  statement  do  not  gxiarantee 
immediate  completion  of  the  named  task.  Completion  must  happen  no 
later  chan  when  the  Cask  reaches  a  synchronization  point. 

4.1.1.10.2  Determine  when  an  aborted  cask  is  complete  from.  When  a  Cask  has 
been  aborted,  it  may  become  completed  at  any  point  from  the  time 
Che  abort  statement  is  executed  until  its  next  synchronization 
point.  Depending  on  when  an  implementation  actually  causes  the 
cask  to  complete  the  results  of  an  aborted  may  be  different. 

tfhat  are  the  results  if  a  task  is  aborted  while  updating  a 
variable?  An  implementation  may  defer  completion  of  a  task  if  it 
is  aborted  while  updating  a  variable,  and  thus  prevent  a  variable 
from  being  undefined.  This  may  be  crucial  in  the  case  of  a  common 
variable. 


4.1.1.10.3 


TARGET  HOUSEKEEPING 
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COMMONLY  CALLED  CODE  SEQUENCES 


MEMORY 


3.12.3.1 

3. 7. 1.1 

3. 7. 1.2 

3. 7. 1.3 

3. 7. 1.4 

3. 7. 2.1 

3. 7. 2. 2 

3. 7. 2. 3 

3. 7. 3.1 

3. 7. 3. 2 

3. 7. 3. 3 

3. 7. 3. 4 

3. 7. 3. 5 


There  are  several  tesc  cases  that  are  run  vlch  the  pragma  OPTIMIZE 
for  option  space.  Determine  the  Improvement  in  the  size  of  the 
object  code  v^en  this  pragma  is  used. 

TIME 

This  test  measures  the  time  to  perform  standard  boolean  operations 
(XOR,  MOT,  OR,  AND)  on  arrays  of  booleans.  The  tests  are 

performed  on  entire  arrays. 

This  test  measures  the  time  to  perform  standard  boolean  operations 
(XOR,  NOT,  OR,  AND)  on  arrays  of  booleans.  The  tests  are 

performed  on  components  of  arrays. 

This  test  measxire  the  time  to  perform  assignment  and  comparison 
operations  on  arrays  of  booleans. 

This  tesc  measures  the  time  to  perform  assignment  and  comparison 
operations  on  whole  records. 

Measure  the  time  to  do  an  unchecked  conversion  of  one  integer 
object  to  another. 

Measxire  the  time  for  UNCH£CKED_CONVERSION  to  move  a  STRING  object 
to  another  INTEGER  object. 

Measure  Che  time  to  do  an'unchecked  conversion  of  an  array  of  10 
floating  components  into  a  record  of  10  floating  components. 

Measure  the  time  to  score  and  extract  bit  fields  using  Boolean  and 
Integer  record  components.  12  accesses,  5  scores,  1  record  copy. 

Measure  the  time  to  storage  and  extract  bit  fields  that  are 
defined  by  nested  representation  clauses  using  packed  arrays  of 
Boolean  and  Integer  record  components. 

Measure  the  time  to  perform  a  change  of  representation  from  one 
record  representation  to  another. 

Measure  the  time  to  perform  a  change  of  representation  from  a 
packed  array  to  an  unpacked  array. 

Measure  the  time  to  perform  POS,  SUCC,  and  FRED  operations  on 
enxuBeration  type  with  representation  clause  specification. 
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3.10.1.2  Determine  the  time  to  convert  integer  to  Float  using  Float  (I)  and 

vice-versa  using  Integer  (F) . 

3.10.2.1  Determine  time  required  for  float  matrix  multiplication. 

3.10.2.2  Measure  the  time  for  a  ftinction  that  computes  the  inner  (scaler) 
product  of  two  values  of  type  Vector  where  Vector  is  the 
following;  type  Real  is  digits..,;  type  Vector  is  array  (Integer 
range  O)  of  Real; 

3.11.2.1.1  Measure  the  overhead  and  procedure  call  latency  involved  in 
entering  and  exiting  a  subprogram. 


3.11.2.2.1  Repeat  benchmarks  from  above  with  pragma  INLINE  for  the  called 
procedure . 

3.11.2.3.1  Repeat  benchmarks  from  above  with  the  called  subprogram  being  part 
of  another  package. 

3.11.2.4.1  In  the  tests  for  inter-  and  intra-package  calls,  the  subprograms 
are  part  of  generic  packages  that  are  instantiated. 

3.12.1.1  Determine  improvement  in  execution  speed  when  pragma  Suppress  is 
used  for  the  following  checks: 

5. 1.1.1  Measure  time  for  a  simple  producer -consumer  type  transaction  when 
the  main  procedure  calls  a  conswer  task. 

5. 1.1. 2  Measure  time  for  a  producer -consumer  type  transaction  when  the 
consumer  uses  a  selective  wait.  In  this  test  the  main  task  calls 
a  consumer  task  that  consumes  more  than  one  type  of  item. 

5. 1.1. 3  Measure  time  for  a  producer -consumer  type  transaction  when  a 
producer  task  calls  a  consumer  task. 


5. 1.2.1  In  this  benchmark,  the  producer  task  communicates  with  the 
consumer  task  indirectly  through  a  bounded  buffer. 

5. 1.3.1  In  this  benchmark,  a  producer  task  communicates  with  a  consumer 

task  indirectly  through  a  bounded  buffer  with  a  transporter 

between  the  buffer  and  consvimer. 

5. 1.4.1  In  this  benchmark,  a  producer  task  communicates  with  a  consumer 

task  indirectly  through  a  bounded  buffer  with  a  transporter 

becweerT  the  buffer  and  the  producer  as  well  as  between  the  buffer 
and  the  consumer. 

5. 1.5.1  In  this  benchmark,  a  producer  task  communicates  with  a  consumer 
via  the  relay.  In  terms  of  the  task  communication  model,  this 
resembles  the  producer-buffer-transporter-consximer  paradigm,  but 
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3.12.2.1 

3.12.2.2 

3.12.3.1 

FOOOOOl 

F000002 

LOOOOOl  - 

L000002 

L000003 

FOOOOOl 

P000002 

P000003 

P000004 

P000005 

P000006 

P000007 

POOOOlO 


in  terns  of  perfomance  it  should  resemble  the  producer 'buffe  r- 
consumer  paradigm. 

Determine  the  overhead  due  to  Pragma  SHARED  ^en  two  tasks  access 
a  packed  array  of  boolean  shared  variable. 

Determine  the  rendezvous  time  when  shared  variable  is  updated 
during  the  rendezvous. 

There  are  several  test  cases  that  are  run  with  the  pragma  OPTIMIZE 
for  option  tine.  Determine  the  improvement  in  execution  time  of 
the  object  code  when  this  pragma  is  used. 

Time  to  set  a  boolean  flag  using  logical  eqxiation.  A  local  and  a 
global  integer  are  compared.  Compare  this  test  with  F000002. 

Tine  to  set  a  boolean  flag  using  an  "if"  test.  A  local  and  a 
global  integer  are  compared.  Compare  this  test  with  FOOOOOl. 

Simple  "for"  loop  time  for  1  in  1..100  loop  time  is  reported  for 
once  through  loop. 

Simple  "while"  loop  time  while  I  less  than  or  equal  to  100  loop 
time  is  reported  for  once  through  loop. 

Simple  "exit"  loop  time  loop  1;-I  +  1;  exit  when  I  greater  chan 
100;  end  loop;  time  is  reported  for  once  through  loop. 


Procedure 
parameters . 

call 

and 

return 

time. 

Procedure 

*is 

local,  no 

Procedure 

call 

and 

return 

time. 

Procedure 

is 

local,  no 

parameters,  when  procedure  not  inlineable. 

Procedure  call  and  return  time.  Procedure  is  in  a  separately 

compiled  package.  Compare  to  P000002. 

Procedure  call  and  return  time.  Procedure  is  in  a  separately 

compiled  package.  Pragma  Inline  used.  Compare  to  FOOOOOl. 

Procedure  call  and  return  time.  Procedure  is  in  a  separately 

compiled  package.  One  parameter,  in  INTEGER. 

Procedure  call  and  return  time.  Procedure  is  in  a  separately 

compiled  package.  One  parameter,  on  INTEGER. 

Procedure  call  and  return  time.  Procedure  is  In  a  separately 

compiled  package.  One  parameter,  in  out  INTEGER. 

Procedure  call  and  return  time.  Compare  to  P000005.  10 

parameters,  in  INTEGER. 
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POOOOll  Procedure  call  and  return  cine.  Conpare  to  P000005  and  POOOOIO. 

20  parameters ,  in  INTEGER. 

P000012  Procedure  call  and  return  time.  Compare  to  POOOOIO  (discrete  vs. 

composite  parameters).  10  parameters,  in  MY^RECORD,  a  three 
component  record. 

P000013  Procedure  call  and  return  time.  20  composite  "in"  parameters. 

The  package  body  is  compiled  after  the  spec  is  used. 

IF-.AND-HOU 


Determine  if  pragma  CONTROLLED  has  any  affect  for  a  access  type 
object. 

Determine  order  in  which  actual  parameters  to  a  subprogram  are 
evaluated? 

4.6.2  '  Determine  order  in  which  parameters  of  modes  out  and  in  out  are 

copied  back  at  the  completion  of  a  subprogram  call. 


3.12.4.1 

4.6.1 
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APPENDIX  G 


GLOSSARY 

These  definicions  ere  being  presented  to  facilitate  the  understanding  of 
this  report. 


Ada  Runtioe  Environment  •  A  set  of  all  capabilities  provided  by  three  basic 

elements:  predefined  subroutines,  abstract  data  structures,  and  code 

sequences  [ARTEVG  1988] 

Analysis  -  the  interpretation  and  classification  of  signals,  also  the  portion  of 
software  that  determines  the  next  course  of  action  based  on  the  data 
collected 

Direction  Finding  -  process  of  making  various  measurements  that  will  provide  an 
indication  of  the  direction  from  which  a  signal  originated  [ESL  Corporation 
1985] 

Emitter  Location  •  the  computed  location  of  a  target  [ESL  Corporation  1985] 

Intercept  •  determining  signal  presence  and  recording  or  monitoring  it  [ESL 
Corporation  1985] 

Macro  Construct  •  set  of  Ada  statements  that  perform  a  well>defined  process 

Micro  Construct  •  indlvidxial  Ada  statement 

Real-Time  -  software  chat  constantly  monitors,  analyzes,  and  responds  to  external 
physical  events  in  a  time-critical  fashion  [Mellichamp  1983] 

Reporting  -  disseminating  analyzed  data  [ESL  Corporation  1985] 
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APPENDIX  H 


GLOSSARY  OF  ACRONYMS 

AD  •  Air  Defense 

ANSI  •  American  Naclonal  Standards  Institute 

AQL  *  Advanced  Quick  Look 

BFA  -  Battlefield  Functional  Area 

CECOM  •  Communications  and  Electronics  Command 

CUAALS  •  Communication  High  Accuracy  Airborne  Location  System 

COMINT  -  Communications  Intelligence 

DoD  •  Department  of  Defense 

DF  -  direction  finding 

DS  •  directed  search 

ECS  •  Embedded  Computer  System 

ELINT  -  Electronics  Intelligence 

FS  *  Fire  Support 

GS  •  general  search 

IC/SD  -  Intercom/Spectrum  Display 

lEV  -  Intelligence  Electronic  Warfare 

IGRV  •  Improved  Guardrail  V 

I/O  -  Input/Output 

LOP  •  Line  of  Position 

LRM  •  Language  Reference  Hanxial 

MC  •  Maneuver  Control 

PDL  •  Program  Design  Language 

RDLS  •  Reporting  Data  Link  Subsystem 

RTE  •  Runtime  Environment 
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SCAR  -  Signal  Classification  Recognition 
SCT  -  Signal  Classification  Tips 
SEl  -  Software  Engineering  Institute 
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